FoxTalk

Solutions for Microsoft® FoxPro® and Visual FoxPro® Developers

April 1999
Volume 11, Number 4

1 Turn Your VFP App Client/

Server: A 12-Step Program

Turn Your VFP 3

Jim Falino
Editorial: The Dismantling
of Microsoft

App Client/Server: 9
Whil Hentzen
Driving the Data Bus:
Third-Party Reporting Tools

A 12-Step Program 14
Andrew Coates
Solving a Mystery
Michael Levy

17 What’s Really Inside:

Jim Falino 6.0 The Basics of Buffering
Jim Booth

20 The Kit Box: Buffering:

Have any of your clients or your boss yet asked you, “What will it take to make this The Transaction Slayer
VFP application access a SQL Server back end?” Well, Jim’s been there and done Paul Maskens and Andy Kramek
that. So in this first of a two-part series, he’ll show you how to re-architect your 23 April Subscriber Downloads
application in order for it to access, literally, any ODBC-compliant data source. In
EA Best Practices: Seeing Patterns:
fact, with the proper planning and design, you’ll see how your application can Chain of Responsibility
even access Visual FoxPro tables as well. This will enable you to prototype your Jefferey A. Donnici
application against Fox data before deploying it on a remote data source. EA Reusable Tools: Building
a Builder Builder

T
HE “big question” was asked of me about three years ago and— Doug Hennig
fortunately—it was asked before I began writing even a single line of EA Visual Basic for Dataheads:
code. That was the good news. The bad news was that the same set of A Command and Function
code was expected to access native Visual FoxPro tables if a client didn’t have Summary—Part 2
Whil Hentzen
a need for the features of a powerful and much more expensive RDBMS, like
MS SQL Server. That might sound like a daunting task, but with the kind of
forewarning I was given, coupled with the flexibility of VFP, I was able to 6.0
satisfy the project’s requirements.
Applies to VFP Applies to Applies to Applies to
All it really takes is an understanding of how client/server applications v6.0 (Tahoe) VFP v5.0 VFP v3.0 FoxPro v2.x
work. If you can achieve that, then it’s just a matter of making sure that
everything you code will work under both scenarios. That being said, the goal
of this article isn’t just to explain how to make a VFP application access a SQL Accompanying files available online
at http://www.pinpub.com/foxtalk
Server database, but also to alert you to the pitfalls of file-server development
that would require a complete redesign.
Applies specifically to one of these platforms.
Continues on page 4
2 FoxTalk April 1999 http://www.pinpub.com
 From the Editor FoxTalk

The Dismantling of Microsoft

Whil Hentzen

I
F you haven’t heard the news by now, you’ve probably company. And while Microsoft competes so hard as to be
been living in a cave, but I’ll repeat it for those few of overwhelming, it doesn’t have the blatant disdain for the
you who are unaware. The United States Department law that the Trusts of a century ago openly carried.
of Industry, Commerce, and Knowledge has prevailed However, the charges of monopolistic practices and
in their various legal machinations against our generous unfair bundling of products are very similar to those of
benefactor and beloved parent of Visual FoxPro— Roosevelt’s administration, and these must have formed
Microsoft Corporation—and has proposed a plan to the basis for the government’s decision on how to break
divide Microsoft into multiple businesses in order to up Microsoft.
alleviate the charges of monopolistic practices and unfair Pundits have guessed that the company would be
bundling of products. As FoxPro’s journal of record for divided into product lines, such as operating systems,
the past 11 years, it’s only appropriate to describe what home-based (or “edutainment”) products, development
that plan is and what it means to you. tools, and so on. This was a completely reasonable
First, I’m going to point out some background that assumption, of course, both because of the charges
will help you understand the reasoning behind the plan, that profits from one product or product group were
and to provide you with additional information that unfairly used to subsidize another product, and because
will help you make your own plans during these Microsoft’s actual organizational structure along those
tumultuous times. lines made it easy to see how the breakup would be done.
In the late 1800s and early 1900s, industrialists Continues on page 23
(what they called “businessmen” back then) would
use a combination of shrewd business knowledge,
unscrupulous practices, and blatantly illegal techniques
to form a company that dominated the industry it was
in. John D. Rockefeller, as many of you know, was
perhaps the most well-known of these industrialists,
having formed the world’s largest corporation and
effectively monopolized the domestic oil business. He
continued to buy competitors or put them out of business,
in all aspects of oil production, from discovery to refining
to distribution. This combination of a broad range of
companies was popularly referred to as a “Trust,” such
as in the “Standard Oil Trust.”
Teddy Roosevelt went after the Trust and broke it
up because of a personal blood feud with Rockefeller.
Standard Oil was divided into multiple companies, each
geographically restricted. Thus, we had Standard Oil of
Illinois, Standard Oil of New Jersey, Standard Oil of Ohio,
and so on. Some changed their names (SO-New Jersey to
Exxon, Standard Oil of Ohio to SOHIO, and then to
British Petroleum, and so forth).
Today, some aspects of the legal battle between
Microsoft and the government are similar, and some are
different. For example, the term “Trust” isn’t ever used
when referring to Bill Clinton’s administration or
Microsoft’s far-flung operations, and there isn’t any
personal animosity between the commander-in-chief and
the head of the world’s largest independent software

http://www.pinpub.com FoxTalk April 1999 3

A 12-Step Program . . .
Continued from page 1
If you’re in the same position I was, then this article
will come in quite handy. It will serve as a guide to
developing a client/server application where VFP is used
only as the front end. (Actually, VFP could be used as the
middle tier as well, but to keep focus on the database,
assume a two-tiered, or fat client, client/server model.) If
you’ve already begun, or even finished, a file-server
application that needs to be upsized, this article will
enable you to determine how much work you have on
your hands.
Some might be wondering why I’m not mentioning
the possibility of using a VFP back end through ODBC as
well. I’ve tried that and found that the limitations of the
VFP ODBC driver made it unworthy of my effort. If
you’re going to use VFP in a file-server environment, you
might as well enjoy all of its benefits and not be hampered
by driver limitations.
It’s all about views and wrappers
I’ve cataloged the issues you’ll need to be aware of into a
12-step program (everybody has one, why shouldn’t I?).
There are two central themes running through the 12
steps—views and wrappers. If you can keep these two
concepts in mind at all times, you can’t go wrong. By the
way, the 12 steps aren’t in any particular order. I’ll cover
steps 1-6 this month and steps 7-12 in Part 2 of this series.
Views, as you probably already know, are nothing
more than SQL statements stored in a database container.
They come in two varieties—local views and remote
views. Local views are used to access VFP data only.
Remote views can be used to access any ODBC-compliant
data source. VFP’s implementation of views allows you to
work with them in much the same way you work with
native tables. As I’ll cover in detail in this article, making
use of them is a key to being back-end-independent.
The other important concept is the use of wrappers.
By wrapper, I’m referring to the technique whereby a
function or command, like SKIP, is “wrapped” in some
protective code and housed in a user-defined function so
that each time it’s used, you don’t have to re-code the
necessary error trapping. For instance, Function SafeSkip
might look something like this:
Function SafeSkip
LParameters cAlias
llMoved = .F.
* Avoid that "EOF encountered" error
If !EOF(cAlias)
Skip In (cAlias)
If EOF(cAlias)
* Moved to EOF, retreat
Skip –1 In (cAlias)
Else
llMoved = .T.
Endif
4 FoxTalk April 1999
Endif
Return llMoved
I believe design pattern zealots call this a Decorator
pattern—a term that means to “pretty up” some
unfinished code. Whatever you want to call it, it’s
imperative to create “hooks” in your code and not to
hard-code anything that might have to be dealt with in
different ways depending on the back end. These
techniques provide opportunities for you to write
conditional code. The more data sources you intend to
access, the more conditional code you might need.
Writing code in this manner will provide you with the
following benefits:
• It creates a single point of maintenance if a change
needs to be made.
• The same code can access multiple data sources.
• You can begin coding a client/server application
using a VFP back end until a decision has been made
on using MS SQL Server, or Oracle, or Informix, or
Sybase, or DB/2, and so on.
Step 1. View-based data entry forms
When it comes to data entry forms for a VFP client/
server application, you can use either SQL Pass-through
(SPT), which is simply passing a SQL string through
ODBC to the data source, or remote views, meaning
DBC-stored SQL statements whose resultant temporary
tables act much like native VFP tables. SPT will store its
result set in a local cursor, so you’d have to then loop
through the controls on a form and bind each of them
individually (for instance, thisform.txtCustomer.Value =
SQLResult.customer). Of course, updating the server
would require you to create the appropriate SQL Update,
Insert, and Delete statements yourself, not to mention the
multi-user contention checking that must be coded as
well—a rather tedious, error-prone task. This is the way
things are typically done in Visual Basic (so you know
there must be a better way with VFP <g>).
Remote views, on the other hand, are incredibly
simple to work with. All you need to do is create a
view with the same structure as the underlying table,
open the view (perform the SQL Select), manipulate
the local temporary table it creates in the same way you
would a native FoxPro table, then issue TableUpdate.
TableUpdate automatically creates the SQL Update,
SQL Insert, and SQL Delete statements for you and
passes them to the ODBC driver manager on your
workstation. The ODBC driver manager uses the ODBC
driver you’ve chosen to translate the SQL into a syntax
that the back end understands. It’s that simple. I
recommend using remote views for data entry forms
for the following reasons:
http://www.pinpub.com
 • One code set. The same set of code can work against
VFP tables or remote tables on a SQL Server. You’ll
just use local views or remote views accordingly.
• Performance. In many ways, views can be faster than
SPT because TableUpdate (a low-level VFP function)
automatically creates the SPT code for you. The time
it would take to create the SQL update strings
yourself and execute the code would most likely be
longer than TableUpdate. If you think about how
much TableUpdate actually does—scanning the
change buffer, determining the type of update made,
reading view properties, building the batch of SQL
statements, passing them to the ODBC driver
manager, returning a success/failure flag, and
clearing the change buffer—I’m sure you’ll agree that
it can outperform SPT.
• All of the above can be done without a syntax error.
• Properties of views offer additional functionality over
SPT. For example, to simulate a BatchUpdate count of
five, you’d need to concatenate five SQL statements
with semicolons before passing them to ODBC.
SPT does still have a very important place on a
client/server application; I’ll discuss it more in Step 3. For
more information on the basic usage of local and remote
views, refer to the VFP Developer’s Guide.
Step 2. All data-related commands should
funnel through one function
About the worst thing you can do to make converting
your application to a client/server design difficult is to
hard-code data access commands like SQL statements,
Zap, Pack, Reindex, Seek, and so forth, within your code.
In other words, does your code look like the following?
Function PurgeOrders
* This function purges (deletes) orders shipped
* prior to the date passed.
LParameter dShipDate
Local lcMsg
Select Count(*) as OrderCnt from Orders ;
Where ShipDate <= dShipDate Into Cursor tcPurge
If _Tally = 0
lcMsg = "There are no orders to purge."
Else
Delete from Orders Where ShipDate <= dShipDate
lcMsg = Trim(Str(_Tally)) + ;
" orders were purged from the system."
Endif
MessageBox(lcMsg)
EndFunc
These kinds of SQL statements are only good to
access tables that can be found along your path. In the
client/server world, you communicate with a data
source via a connection handle. For views, the Remote
Connection <ConnectionName | DataSourceName>
clause of the Create SQL View command enables a view
to access remote data. And for in-line SQL, the FoxPro
http://www.pinpub.com
function SQLExec() is used to pass SQL statements
through to the server via ODBC. It returns -1 for an error,
1 for success, and 0 if an asynchronous query has yet to
complete. As an example, here’s how to get a cursor of
sales orders for a given customer using SQL Pass-through:
llSuccess = SQLExec(goEnv.nHandle, ;
"Select * From ORDERS Where Customer = ?cCustomer",;
"tcOrders") > 0
If you’d employed a wrapper function for the SQL
Select statements in PurgeOrders, then you could
conditionally run it against data on a SQL Server, data
on a file server, or even data on the local workstation.
You should create classes of just such functions to make
data access back-end-independent. Here’s Function
PurgeOrders rewritten in a client/server fashion:
Function PurgeOrders
* This function purges (deletes) orders shipped
* prior to the date passed.
LParameter dShipDate
Local lcSQLStr
lcSQLStr = "Select Count(*) as OrderCnt " + ;
"from Orders " + ;
"Where ShipDate <= ?dShipDate"
This.SQLExecute(lcSQLStr, "tcPurge")
If Reccount("tcPurge") = 0
lcMsg = "There are no orders to purge."
Else
lcSQLStr = "Delete from Orders ;
Where ShipDate <= ?dShipDate"
This.SQLExecute (lcSQLStr)
lcMsg = Trim(Str(Reccount("tcPurge"))) ;
+ " orders were purged from the system."
Endif
MessageBox(lcMsg)
EndFunc
Function SQLExecute
* Wrapper for VFP function SQLExec
LParameters cExecuteStr, cCursor
Local llSuccess
cCursor = Iif(PCount() = 1, "SQLResult", cCursor)
llSuccess = .T.
If goEnv.lRemote
llSuccess = (SQLExec(goEnv.nHandle, ;
cExecuteStr, cCursor) > 0)
Else && local, just macro expand cExecuteStr
* Add VFP "Into Cursor..." clause
If Upper(Left(cExecuteStr,6)) = "SELECT"
cExecuteStr = cExecuteStr + ;
" Into Cursor " + cCursor + " NoFilter"
Endif
* This should be error trapped to return llSuccess
&cExecuteStr
Endif
Return llSuccess
EndFunc
You’ll note the use of Reccount() vs. _Tally. SPT
cursors don’t update _TALLY, so you’ll have to forget
using this pretty cool system variable. However, you
won’t have to worry about Reccount() containing deleted
records, since remote SQL data sources don’t have a two-
stage delete. And if the back end was a VFP database, the
NoFilter clause would prevent VFP from creating a filter
as opposed to a temporary table.
The second worst thing you can do to make
converting your application to a client/server design
FoxTalk April 1999 5
difficult is to embed VFP functions in your SQL Selects.
However, if you have a wrapper like SQLExecute, you
have an opportunity to parse out the SQL statement
before it executes and convert it to the back-end-specific
syntax. For instance, the SQL Server function Convert() is
used to convert data types. So, you could probably
imagine what the code would look like to find “Str(” or
“Val(” in a string and StrTran() the Convert function in its
place. One last option is to remove the embedded function
and make the SQL statement back-end-independent, then
use the VFP-specific function on the local cursor.
Step 3. Use stored procedures
or parameterized queries
In terms of execution speed, there’s nothing faster than a
stored procedure (SP). Since they’re precompiled and live
in the same building as the tables, what could be more
efficient? The way that parameters need to be passed to
back ends is often different, so, again, a wrapper function
comes in handy here. For example, notice the different
syntax between VFP and SQL Server:
SQLExec("usp_GetOrders('Acme')") && VFP
SQLExec("usp_GetOrders 'Acme'") && SQL Server
All you’d need to do to solve this is enhance the
SQLExecute wrapper function to handle stored
procedures. (I’ll leave that manageable task to you.)
If you don’t want to go the stored procedure route,
there’s always parameterized queries stored in business
objects. With parameterized queries, you wouldn’t have
to worry about back-end-specific stored procedure call
syntax, nor would you have to worry about rewriting
the stored procedures for each data source. The hit
you take in performance might be worth the boost
in maintainability.
You’ve already seen what a parameterized query
looks like—it’s just an SPT statement:
llSuccess = SQLExec(goEnv.nHandle, ;
"Select * From Orders Where Customer ;
= ?cCustomer", "tcOrders") > 0
Notice the syntax of the filter condition: Customer =
?cCustomer. That syntax is important because: 1) most
back ends support it; and 2) it prevents you from having
to build the parameters of the SQL statement into a back-
end-specific character string:
Case lSQLServer
"...Customer = '" + cCustomer + "' And ;
shipdate <= '" + DTOS(dShipdate) + "'"
Case VFP
"...Customer = '" + cCustomer + "' And ;
shipdate <= {" + DTOS(dShipdate) + "}"
Another benefit is that you won’t run into the
dreaded “apostrophe bug.” It occurs when you try to
6 FoxTalk April 1999
build a SQL statement like the preceding one, but the
variable (in this case, cCustomer ) has an apostrophe in
it (for instance, “Jim’s”). Since its value is evaluated
before the string is sent to the server, you’ll end up with
mismatched quotes and an error at execution time. As you
can see, the use of the “?” can really tighten your code, so
I highly recommend its usage.
For the preceding reasons, I recommend SPT instead
of views whenever you’re creating an ad hoc query
and/or don’t intend to update the data source. Many
people create views for reporting purposes, but for a
large system, I can’t see incurring the overhead of using a
view when a stored procedure or SPT SELECT statement
can be deployed instead. (Unless you wanted to expose a
server-side view to your users.) The client-side DBC of
views can get quite bloated with data it doesn’t need to
maintain, since there are no view properties that really
need to be set.
Step 4. Find creative ways to limit result sets
In the client/server paradigm, record sets are transferred
from the server to the local workstation; thus, they should
be as small as possible in order to reduce network traffic.
Therefore, unlike the way the typical VFP file-server
application functions, forms should open without data.
That will also help maintain a snappy form load, even as
your data grows beyond the capacity of file-server
databases, like VFP.
And if you think about it, it does make sense to give
users only what they’re looking for. Why present a user a
with grid that has 10,000 open sales orders when he or she
can only work with one customer at a time? I think we
programmed like that for so long because incremental
search utilities made for quick navigation of even large
amounts of data. While that still might be acceptable for
small systems, the load would become unbearable on a
network, and your application wouldn’t scale as data and
users grow.
Parameterized views
So if your forms open without data in the client/server
world, how do we go about getting data? You need to
provide your users with a facility for entering filter
criteria. These values will serve as parameters of the
Where portion of the view’s SQL statement. You can
provide this functionality in many different ways—your
choices range from the very simple to the very complex.
A simple implementation is to have a form bound to a
parameterized view. When a user enters Find mode, you
then provide a text box for entering the parameter value.
For example:
* Create this view when you create the form.
Create SQL View vOrders As Select * From Orders
Where Customer = ?cCustomer
* Open the view (with no data) in the Data Environment
http://www.pinpub.com
* or Load when you run the form.
Use vOrders NoData
* Get the customer parameter in Find Mode
cCustomer = thisform.txtCustomer.Value
Requery() && retrieve orders for cCustomer
A second technique that would provide much more
flexibility is to provide a Query-By-Form (QBF) facility.
QBF means that in Find Mode, you provide for the user a
way to enter filter criteria into any (or just most) of the
controls on a form. You then build a SQL Where string
accordingly and use it in one of two ways:
1. Build an SPT statement to create a record set of the
important fields and the unique ID. Create a view
that’s parameterized on a unique ID. Users can
browse the SPT cursor to find the data they need, and
you can requery the view based on the unique ID.
2. You can also use the QBF-generated SQL string to
recreate the remote view definition on the fly. Since
your DBC of views is on the workstation, there’s no
contention issue here. (More on this in Step 5.)
Tip!
There are at least two third-party tools available for
implementing Query-By-Form in VFP:
• QBF Builder (http://www.hallogram.com/qbfbuilder)
• Stonefield Query (http://www.stonefield.com)
Handling controls bound to look-up tables
This concept of limiting result sets should be applied to
controls as well. What good is limiting sales orders to
one customer if you’re going to populate several combo
boxes on your form with look-up table data? The several-
thousand-record list box or combo box control has no
place in a client/server application. There are at least two
ways of getting around this problem. One is to not use
these kinds of controls on large tables and instead use a
text box. Then just launch a separate form with a grid
upon the user choosing a hot key.
If you insist on using multi-record controls, you can
try a second technique. Don’t populate the control until
the GotFocus event is fired. This late-binding technique
will save you the overhead of populating unused
controls. You can also use a combination of each of these
techniques depending on the anticipated size of the look-
up table, and just control it with a property and/or
options table.
The VFP Developer’s Guide offers yet another
suggestion: copying often-used lookup tables to each
workstation. However, knowing when to keep the local
http://www.pinpub.com
version in synch with the server version sounds like a
nightmare to me. Therefore, I recommend one of the
other options.
One-to-many forms
One-to-many forms should be handled as follows.
Whatever technique you’ve decided to use for single-table
forms should also be used for the header portion of a
one-to-many form. The views of child tables should be
parameterized on the unique ID of its parent. So, when
you navigate from one header to another, the child view
just needs to be requeried. Using this method, only the
children of the current header need to be brought locally.
Step 5. Keep views in their own DBC
to treat the back end independently
If, in your framework design, views are maintained in
their own DBC, it will make the transition to other back
ends more seamless. In other words, when you want your
application to access a different data source, you want to
keep as many pieces of your framework still intact.
Keeping your views in a separate DBC from the tables
(in a VFP back-end scenario) will make accessing a
remote data source a matter of flipping a switch. The
implementation could be as follows:
• Create a directory called \VFPViews, and store a DBC
of local views in it. Name the DBC AppViews.DBC
(\VFPViews\AppViews.DBC).
• Create a separate directory for each data source
you wish to access, keeping the view’s DBC name
the same. In other words, the DBC \SSViews\
AppViews.DBC would contain views that access a
SQL Server. Since there are often several places in
your code where you’ll refer to the views database,
this will prevent your having to write conditional
code per back end.
• In an initialization file of your choice, store
information like the ODBC DSN name, the
directory path where the views are stored, a flag
indicating whether you’re accessing local or remote
data, and, if local, the directory path of where the
VFP tables are stored.
• Set Path To... the appropriate views directory on
application startup.
• If it’s a VFP back-end, Set Path To... the network
directory where the VFP tables are stored.
While it’s true that you could add the name of the
views database to the initialization file as well, often
this is already hard-coded throughout an application.
Having a separate DBC of views will also keep the size
of it manageable. If the back end was a VFP database,
FoxTalk April 1999 7
combining them would mean that twice the number of
database objects would need to be stored. If such was the
case, Modify Database could take forever on a large
system. You’ll also notice that the view’s DBC (regardless
of whether it contains local or remote views) is kept
locally, not on a network to be shared by all users. Using
this technique will allow for a lot of user-specific
flexibility, as you’ll learn later in the article.
This whole piece feels like it’s assuming a local store
as well, but it’s not explicitly said.
Step 6. Use Locate rather than Seek
for local data navigation
Since all data is accessed via SQL statements in a client/
server application, you lose the ability to use every VFP
developer’s best friend—Seek. Wipe those tears, there’s
an alternative: Locate. Since local result sets will be (by
client/server definition) relatively small, the Locate
command will more than suffice for moving the record
pointer in a local cursor or temporary table.
Here’s even better news. The result set of a view is
actually a temporary table. To see what I mean, open any
view and check out the return value of ? DBF(). You
should see something like C:\WINDOWS\TEMP\
76633985.TMP. So this “thing” actually has a disk
presence. And in VFP, if it has a disk presence, we can
8 FoxTalk April 1999
index it. So, feel free to index a view’s cursor as much as
you’d like if you feel you need the speed. But I’d still stick
with Locate over Seek. Since Locate is also Rushmore-
optimizable, using it with or without an index won’t
fail—one will just be marginally faster than the other.
Conclusion
Well, we’re only halfway there, but already I’m sure
you can see the writing on the wall. Wrappers and views
are certainly the keys to making your code back-end-
independent. Keeping those concepts in mind at all times
will give you the leverage you need to make a flexible,
scalable client/server application. Next month, I’ll cover
six more steps and close with a sample form that can
access a VFP database as well as a SQL Server database.
Then, you’re on your own. See you next month. Until
then, start wrapping. ▲
Jim Falino has been happily developing in the Fox products since 1991,
beginning with FoxBASE+. He’s a Microsoft Certified Professional in
Visual FoxPro and the vice president of the Professional Association
of Database Developers (PADD) of the New York Metro Area. For the
past three years, he’s been a project manager, leading the development
of a very large client/server apparel-manufacturing application for
the GARPAC Corporation using Visual FoxPro as a front end to any
ODBC-compliant SQL back end. jim@garpac.com.
http://www.pinpub.com
 Driving the Data Bus FoxTalk

Third-Party Reporting Tools

Andrew Coates 6.0

Getting the data into an application’s tables is only half the
battle. Some even say it’s the easy half. In the second column
of this series, Andrew discusses some of the third-party tools
you can use to convert this data into valuable information.
analysis and reporting tasks much better, faster, and more
efficiently than the Fox ever will. This isn’t a reflection on
FoxPro; it’s simply an acknowledgment of the fact that it’s
much more efficient to use the tools that were designed
for a task to do that task.

L
AST month, I reviewed VFP’s native reporting
tools—SQL, the Report Writer, and the cross-tab
generator (see “Reporting—Converting Data into
Information”). This month, I’ll concentrate on some of
the third-party reporting tools that are available and
compatible with VFP. I’ll discuss interfacing with Excel,
getting your reporting output onto the Web (and a
number of other output options), and putting your data
onto a map.
Demonstration data set
To make this discussion more practical, I’ve developed a
data set I’ll use throughout this series. The database
container and the associated tables are included in this
month’s Subscriber Downloads at www.pinpub.com/
foxtalk. The data set represents a sales contact
management system for a fictitious company, Maroubra
Mapping (MM). There are tables for the company
details, address details, and contact (employee) details,
and a call table that records all interactions between
MM and contacts. There are also lookup tables for some
of the fields.
Why use third-party tools?
I spent much of last month’s article telling you how
wonderful FoxPro’s reporting features are. Why should I
now spend this month telling you how to use other tools,
which are both less well-integrated with VFP and an
additional expense? The simple answer is “horses for
courses.” There are tools available that will do some
Some examples of analysis that can be done better by
other tools instead of FoxPro are shown in Table 1.
There are tools that do some reporting tasks better
than FoxPro, too. Examples are listed in Table 2.
I’m going to cover analysis and reporting in separate
sections, and I’ll give some examples of each of the tasks
in Tables 1 and 2.
Principles of using third-party tools
When using third-party tools from FoxPro, there are three
things I try to do:
1. Minimize the inter-application interface;
2. Utilize the strengths of each tool; and
3. Modularize the tools used.
Minimize the interface
One of the least efficient aspects of any multi-tool
application is the interaction between the tools. Wherever
possible, keep the actual calling of one tool’s functions
from another to a minimum. Usually, the best way to do
this is to write macros or programs in the tool you’re
controlling and just initiate those macros from the tool
you’re using to do the controlling.
Utilize strengths
This might sound obvious, but the reason you’re using
multiple tools is to get the best out of each of them.
Do data handling in FoxPro—it’s very good at it. Do
numerical modeling in something else. Make sure

Table 1. Examples of analysis tasks that can be done better Table 2. Examples of reporting tasks that can be done better
by a third-party tool. by a third-party tool.

Task Tool Task Tool

Specialized financial analysis
Geographic analysis
Computationally intensive
numerical modeling
Tool with financial functions
(for example, Excel)
Geographic Information System
(for example, ArcView)
Custom-written numerical model
(for example, Storm Water
Management Model)
Multiple child reports
Geographic reporting (mapping)
Time-based reporting
Tool allowing sub-reports
(for example, Crystal Reports)
Geographic Information System
(for example, ArcView)
Tool capable of displaying animation
(for example, PowerPoint)

http://www.pinpub.com FoxTalk April 1999 9

you’re using a hammer for the nails and a screwdriver
for the screws.
Modularize
Another great advantage of building a system with third-
party tools is that when a better solution comes along,
you can replace a component of your application and
your application will be better. This is easiest if you have
a central hub controlling each of the third-party tools
rather than chaining a whole lot of tools together in
sequence. I like to use FoxPro as this hub and call each
of the other tools from there.
Controlling third-party tools
Using the native FoxPro analysis and reporting functions
is relatively simple. Because they’re built into FoxPro,
there are FoxPro commands and functions that call them
and control them. Using third-party tools poses more of
a problem, however. These tools weren’t necessarily
developed with FoxPro in mind.
OLE
Fortunately, many of the modern Windows-based tools
(including VFP) use the OLE standard for inter-process
communication. This means that as long as you know
what the tool is registered as and what its object model is,
you can control the tool from within VFP.
I’m not going to discuss the mechanics of OLE
Automation any further in this column, but you can study
the sample files provided with VFP (from version 3 up)
for some examples of how to control Word and Excel.
DDE
Older Windows-based tools might not be OLE servers,
but they might be able to communicate through
Dynamic Data Exchange (DDE). An extension of this
technology is NetDDE, which allows communication
between applications across a network. There’s an
example of calling a DDE server from FoxPro in the
“Mapping” section.
DOS run
Sometimes, there might be no way of directly controlling
your third-party tool from VFP. One analysis package I
use for storm water modeling is a DOS-based system that
requires its own data files and a configuration file. The
way I “control” that tool is to use VFP to extract the data I
need and then write the data and configuration files using
TEXT...ENDTEXT blocks. I can then run the model from a
DOS prompt and use the files I’ve generated. Of course, to
use the output from the model, I need to read it back into
VFP and send it to a reporting package.
Data analysis
While FoxPro does simple data analysis very well, there
10 FoxTalk April 1999
are some tasks that are better delegated to a third-party
tool. Often these are computationally intensive tasks that
aren’t a part of the native FoxPro language, such as
complex financial analysis and numerical modeling.
Another task for which FoxPro isn’t natively equipped is
geographic analysis.
Financial analysis
A common computationally intensive task is financial
calculations. FoxPro offers very little in terms of native
financial functionality—the NPV, or Net Present Value,
clause of the CALCULATE command is the only one
that springs to mind. Excel, on the other hand, has more
than 50 financial functions. These range from ACCRINT
(returns the accrued interest for a security that pays
periodic interest) to YIELDMAT (returns the annual
yield of a security that pays interest at maturity). You
could write any of these functions in FoxPro, but the
computational performance would make this unworkable
for all but the most trivial applications.
Anyway, there’s no need to rewrite any of these
functions in FoxPro if there’s a copy of Excel on the target
machine. For example, Excel provides a function (IPMT)
that calculates the interest paid in a given period of a loan.
If you want to know how much interest you’ll be paying
in the 45th month of a five-year, $145,000 loan at a
percentage rate of 6.6%pa with monthly payments, use
the following code:
oExcel = create('excel.application')
? oExcel.worksheetfunction.IPMT(0.066/12,45,60,145000)
* prints -797.50
release oExcel
In other words, $797.50 of your payment will be
interest. If you want to know what the entire payment
will be (capital and interest), use the Excel function PMT:
oExcel = create('excel.application')
? oExcel.worksheetfunction.PMT(0.066/12,60,145000)
* prints -2843.8882065830
release oExcel
In other words, each payment will be $2843.89.
Note the syntax you use here. First, create an instance
of the Excel OLE Automation server. Next, use Excel’s
worksheetfunction property to call the PMT function.
You get the parameters for the various functions from the
Excel Help files. Finally, release the instance of Excel from
memory. Of course, if you’re calling lots of Excel functions
from your application, just create the Excel instance when
you first need it and release it after you last need it.
Using this technique has the additional distinct
advantage that you can be fairly confident that the
calculations are correct (although, given the recent
spate of discoveries of recalculation bugs in Excel,
some people might dispute this <g>). There’s no need
to rewrite functions that are already available and
http://www.pinpub.com
debugged. Listing 1 shows a program that prints a fixed
interest loan payment and interest schedule using these
two Excel functions.
Listing 1. Using Excel to do financial analysis.
* Program....: PAYSCHED.PRG
* Version....: 1.0
* Author.....: Andrew Coates
* Date.......: January 30, 1999
* Notice.....: Copyright © 1999 Civil Solutions,
* All Rights Reserved.
* Compiler...: Visual FoxPro 06.00.8167.00 for Windows
* Abstract...: Prints a payment schedule for a fixed
* rate loan given an annual interest rate, a number
* of years over which the loan is taken, a loan
* amount, and a number of payments per year.
* Uses the Excel functions PMT and IPMT.
* Changes....:
local loExcel, lnAPR, lnLoanYears, lnLoanAmount, ;
lnPaymentsPerYear
* Set up values for calculations. In practice, you'd
* pass these as parameters or have them as properties
* of an object.
lnAPR = 7.5
lnLoanYears = 10
lnLoanAmount = 250000
lnPaymentsPerYear = 2
loExcel = create('excel.application')
* Calculate the periodic payment.
lnPayment = loExcel.worksheetfunction.pmt( ;
(lnAPR/100)/lnPaymentsPerYear, ;
lnPaymentsPerYear * lnLoanYears, ;
lnLoanAmount)
* Round the periodic payment to the nearest cent.
lnPayment = round(lnPayment, 2)
* Clear the screen.
clear
* Set up the headings.
? 'Period', 'Payment', 'Interest'
* Loop through the periods and calculate the interest
* paid in each.
FOR lnPeriod = 1 to (lnPaymentsPerYear * lnLoanYears)
lnInterest = loExcel.worksheetfunction.ipmt( ;
(lnAPR/100)/lnPaymentsPerYear, ;
lnPeriod, ;
lnPaymentsPerYear * lnLoanYears, ;
lnLoanAmount)
* Round the interest paid to the nearest cent.
lnInterest = round(lnInterest, 2)
* Print the info for this period.
? transform(lnPeriod), transform(lnPayment, '@$'), ;
transform(lnInterest, '@$')
ENDFOR
Numerical modeling
You might be involved in an area that requires numerical
modeling. For example, many engineering applications
use a technique where equations that would otherwise be
deemed insoluble are conquered by successively refined
approximation. Others estimate the state of a system over
a period of time by using the output from a set of
equations as the input to the same set of equations at
small time steps throughout the period. These recursive or
large sequential techniques are obviously very
computationally intensive and as such are best written
http://www.pinpub.com
in a fast, highly optimized programming language.
However, these applications generally also require large
amounts of data to calibrate and also require verification.
We happen to have a system that handles and formats
large amounts of data fast and efficiently (this sounds like
a job for the FOX!).
Many numerical modeling tools are very task-
specific, and as such they don’t have fancy interfaces
like OLE Automation—there just wouldn’t be the return
to the developers for including these abilities. Many of
these tools have an ASCII data file input format, as well
as a configuration file from which all of the parameters
and control values are read. Preparation of these files is
often the most time-consuming and error-prone task in
using these tools, so any automation of the process is a
great boon.
Using FoxPro’s text handling functions, you can
create perfectly formatted ASCII files from your data.
Listing 2 shows an example taken from a program that
prepares an input file for the U.S. EPA’s Storm Water
Management Model (SWMM).
Listing 2. Preparing input files for a numerical model.
* Make sure we've got textmerge turned on.
lcTextMerge = set("textmerge")
set textmerge on
* Open the output file for writing (we'll use
* textmerge).
set textmerge to (lcDataPath + lcOutFile) noshow
* Check that we've opened it sucessfully.
if _TEXT < 0
wait window "Could not open the output file for " + ;
"writing" + chr(13) + PAKTC
return
endif
* Write the program control details.
* Write the block header - $RUNOFF.
\*===============================================
\$RUNOFF
\*===============================================
\
* Write the title lines.
\*===============================================
\* Title Lines (A1)
\*===============================================
\
\A1 '<<alltrim(lcTitle1)>>'
\A1 '<<alltrim(lcTitle2)>>'
\
* Write the B lines (program control).
\*===============================================
\* Program Control Lines (B1-B4)
\*===============================================
\
\* METRIC ISNOW NRGAG INFILM KWALTY IVAP NHR NMN NDAY
\\ MONTH IYRSTR
\B1 <<lcMetric>> <<lcIsnow>> <<lcNrgag>> <<lcInfilm>>
\\ <<lcKwalty>> <<lcIvap>> <<lcNhr>> <<lcNmn>>
\\ <<lcNday>> <<lcMonth>> <<lcIyrstr>>
\
\* IPRN(1) IPRN(2) IPRN(3)
\B2 <<lcIprn1>> <<lcIprn2>> <<lcIprn3>>
\
\* WET WET/DRY DRY LUNIT LONG
FoxTalk April 1999 11
\B3 <<lcWet>> <<lcWetDry>> <<lcDry>> <<lcLunit>>
\\ <<lcLong>>
\ very impressive package. There’s an OLE Automation
* ... stuff omitted
select (lcRainGaugeTable)
index on (lcTimeField) tag (lcTimeField) addi
go top
ltStartTime = eval(lcTimeField)
scan
lnTimeStep= (eval(lcTimeField) - ltStartTime) / ;
iif(lcKtime = "0", 60, 1)
\E3 <<alltrim(str(lnTimeStep))>>
for lnRainGaugeNumber = 1 to alen(laRainGaugeField)
\\ <<eval(laRainGaugeField[lnRainGaugeNumber])>>
endfor
endscan
* remainder omitted
The FoxPro text output functions are fantastic.
They allow recursive embedding of variables, so you
could store all of your file templates in memo fields of
a table and use the <<>> evaluation symbols to expand
the contents of the memo field, which could, in turn,
include <<>> placeholders to allow customization of
the particular instance. I’d urge you to investigate this
often-overlooked feature if you ever need to produce
ASCII text files.
Geographic analysis
Increasingly, users are becoming more interested in the
geographic locations their data represents. Examples
include the suburbs in which customers live for
marketing, the rate of crime for a particular location for
rating an insurance risk, and many other applications.
You’ve probably got a postal code stored with each
address in your customer table, and you can use this, for
example, to determine which regions are generating the
highest sales at each store.
FoxPro is good at answering questions like “how
many sales were from one of the following list of postal
codes?” but isn’t nearly as good at “how many sales were
made to clients living within 30 kilometers of any of our
17 stores?” There are tools that are good at this. They’re
called Geographic Information Systems (GIS), and they’re
database systems that are optimized for geographic data.
Some GIS even have an extended SQL that allows you to
answer queries such as the one posed previously with one
line of code. See the “Mapping” section on the next page
for an example of controlling a GIS from FoxPro.
Advanced reporting
There are some things that the FoxPro reporting system
just can’t do as well as some of the third-party
reporting tools.
Crystal Reports
Arguably, one of the best third-party reporting tools is
12 FoxTalk April 1999
Crystal Reports. Version 7 has just been released and is a
server and an ActiveX control, so you can ship the
runtime files with your application and your client
doesn’t even need a copy of Crystal Reports. There’s a
rich object model that allows programmatic access to a
wide range of reporting options.
Crystal Reports supports a much wider range of
output options than FoxPro does. The destinations
include (but aren’t limited to):
• Exchange folders
• Lotus Notes servers
• ODBC data sources
• Word
• WordPerfect
• Excel
• 123
• E-mail
Crystal Reports also does reporting things that
you just can’t do with the FoxPro report writer. My
favorite example of this is sub-reports. One common
application structure has the company as the parent
table and two child tables—the company’s addresses
and the company’s employees. In FoxPro, there’s no
way to list the addresses and the employees of each
company in the same report. With Crystal Reports, there
is. You can include a sub-report in the detail band of the
main report that essentially runs a parameterized query
against the child tables based on the current value of the
parent table’s primary key. This means that only the
appropriate child table records are printed for each parent
record, and as many child tables as you want can be
included in the report.
You can design reports using the report designer that
ships with Crystal Reports. Calling them from your
application is simple using OLE Automation. Listing 3
shows a VFP program that starts a Crystal Reports
instance, opens a report, refreshes the data in the report,
and prints it out, all from within VFP. Note that if you
want to run this program, you’ll need to create an ODBC
DSN called DataBus that points to databus.dbc, included
in this month’s Subscriber Downloads. You’ll also need
the runtime for Crystal Reports 7.0.
Listing 3. A VFP program that controls a third-party reporting
tool (Crystal Reports) through OLE Automation.
* Program....: CRSIMPLE.PRG
* Version....: 1.0
* Author.....: Andrew Coates
* Date.......: January 27, 1999
* Notice.....: Copyright © 1999 Civil Solutions,
* All Rights Reserved.
* Compiler...: Visual FoxPro 06.00.8167.00 for Windows
* Abstract...: Demonstrates running a Crystal Report
* from within VFP using OLE Automation
* Changes....:
http://www.pinpub.com
* for the MB_ constants If nChan < 0 Then
#INCLUDE foxpro.h MessageBox ([Could Not Connect to ARCVIEW, ] + ;
[Please ensure that it is running], ;
local loCRApp, loCRReport MB_ICONEXCLAMATION)
Return
* Start a Crystal Reports instance. EndIf
loCRApp = create('Crystal.CRPE.Application')
* Build the ArcView command.
* Check that it started OK. cAVCOMMAND = [av.run('SinglePoint', {]
if type('loCRApp') = "O" and ! isnull(loCRApp)
cAVCOMMAND = cAVCOMMAND + ;
* Open a report. ltrim(Str(patientdata.MapNumber)) + [,] ;
loCRReport = .null. + ltrim(Str(patientdata.xValue)) + [,] ;
loCRReport = loCRApp.OpenReport(sys(5) + sys(2003) ; + ltrim(Str(patientdata.yValue)) + [,] ;
+ '\mm1.rpt') + [']+ ltrim(patientdata.nodes) + [','',] ;
+ ['] + ltrim(patientdata.patientname) + [, ] + ;
else upper(ltrim(patientdata.gender)) + ['})]

messagebox('Could not initialize Crystal Reports', ; * Now, run the script.

MB_ICONSTOP, 'Error') cRetVal = DDEExecute(nChan, cAVCOMMAND)
return .f.
* Check to see how the run went, and display an error
endif * if it failed.
If Left(cRetVal, 3) <> [Lay] Then
* Check that the report was loaded OK. msg = [Print Failed - Layout retained as ] + ;
if type('loCRReport') = "O" and ! isnull(loCRReport) Trim(cRetVal) + ;
[. Please print and delete it manually]
* Refresh the data in the report.
loCRReport.Database.verify() answer = MessageBox(msg, MB_ICONEXCLAMATION, ;
"Error Printing")
* Print it out.
loCRReport.PrintOut(.f.) EndIf

else * Terminate the DDE conversation with ArcView.

DDETerminate(nChan)
messagebox('Could not open Report', ;
MB_ICONSTOP, 'Error')
Notice that this program only actually communicates
endif
with ArcView once (apart from initiating and terminating
the DDE conversation). FoxPro does the data handling,
Mapping
and then the ArcView script SinglePoint does the
FoxPro’s native reporting capabilities don’t extend to
reporting work.
mapping. If you need a picture of where things are, you
need to use a third-party tool. Using a GIS, you can lay
Putting it all together
out and visualize the position of objects relative to other
Using FoxPro as the central application, it’s possible to do
objects. You can produce the picture that’s worth a
some pretty complex analysis and reporting. One project I
thousand data points. ArcView is an industry-standard
worked on was the modeling of an urban storm water
desktop GIS. ArcView doesn’t have a fancy OLE
catchment to
Automation interface, but it can be controlled via DDE.
predict the effect
Listing 4 shows a program I used to produce a report
of different
showing where a melanoma was on a patient and the
development
lymph node fields it drained to.
options on the
catchment
Listing 4. Controlling a desktop GIS from FoxPro. response. The
project was
* Program....: RUNARCVIEW.PRG
* Version....: 1.0
broken up into
* Author.....: Andrew Coates two parts,
* Date.......: February 1, 1999
* Notice.....: Copyright © 1999 Civil Solutions, analysis and
* All Rights Reserved. reporting. The
* Compiler...: Visual FoxPro 06.00.8167.00 for Windows
* Abstract...: Calls an ArcView script via DDE to print basic layout of
* the information for this patient
* translated from VBA the components
* Assumes...: patientdata table open and record pointer is shown in
* on correct record
* Changes....: Figure 1.
In the
#INCLUDE foxpro.h
analysis section,
* This module sends data to ArcView via DDE to get it
* to print a map. It passes the map number, randomized non-technical
* x and y values, the node fields comments (blank), and users alter the
* the patient name and sex. Figure 1. Component layout for an
land use of
* First, establish a connection to the DDE server.
analysis and reporting system using
nChan = DDEInitiate([ARCVIEW], [SYSTEM]) third-party tools. Continues on page 19

http://www.pinpub.com FoxTalk April 1999 13


Solving a Mystery
Michael Levy
“Curiosity killed the cat” is how the saying goes. In this article,
Michael continues his series on Visual FoxPro and SQL Server
by demonstrating some of tools that we can use to spy on the
communications between VFP and SQL Server 7.0. Let’s hope
that Michael doesn’t come to the same end as the cat.
I
think that a lot of people are like me and are curious
about how things work—not all things, though, just
computer things. I feel that if I have an understanding
of how it works, I have an advantage over the machine.
Also, as an instructor, the “how does it work” questions
are very common.
The mystery
The mystery that I decided to tackle is the NODATA
option of the USE statement. How does VFP implement
the NODATA clause? For those of you who might not be
familiar with the NODATA option, it instructs VFP to
open a view (either local or remote) but not to fill the
cursor with any data.
I have no way to peer into the inner workings of
VFP. But I do have tools that will allow me to monitor
the communications between VFP and SQL Server.
Somewhere in those communications lies the answer.
Somewhere in those communications, VFP is telling SQL
Server to run a query (or at least evaluate it) and return
the structure of the result set.
The SQL Server Profiler
The SQL Server Profiler is an external tool that ships with
SQL Server 7.0 and is used to monitor and record activity
(called a “Trace”) that occurs on your SQL Server. Events,
such as the submission of ad hoc queries and the
execution of stored procedures, are displayed on the
screen and/or optionally written to a file or a SQL Server
table. A saved Trace can be replayed at a later point in
time or used by the Index Tuning Wizard. The Index
Tuning Wizard will evaluate the queries submitted to the
server against the existing indexes and recommend
changes to the indexes to improve query performance.
We’ll use the Profiler to capture the commands that
VFP sends to SQL Server when it wants to open a remote
view using the NODATA clause.
Creating a Trace
Before you can make use of the Profiler, you have to create
a Trace. A Trace tells the Profiler which events to look for,
14 FoxTalk April 1999
FoxTalk
6.0
what event data to capture, and any filters that should be
applied to limit the data that’s collected.
There are two ways to create a Trace. The easiest way
is to use the Create Trace Wizard. The wizard takes the
approach of solving some common problems like finding
the worst performing queries or identifying the cause of a
deadlock. The other way to create a Trace is to use the
Trace Properties dialog box. The Trace Properties dialog
box can be opened by clicking on the toolbar button or
selecting File | New | Trace. The Trace Properties dialog
box contains four tabs: General, Events, Data Columns,
and Filters.
The General tab is used to capture information like
the name of the Trace, its type, the server to monitor, and
whether to record the captured information to a file and/
or table. A Trace can be one of two types: Private or
Shared. A Shared Trace is available to anyone using the
computer where the Trace was originally defined and is
stored in the Registry under the key HKEY_LOCAL_
MACHINE\SOFTWARE\Microsoft\MSSQLServer\
SQLServerProfiler\Client. A Private Trace is only
available to the person who created it. A Private Trace is
also stored in the Registry under the key HKEY_
CURRENT_USER\SOFTWARE\Microsoft\MSSQLServer\
SQLServerProfiler\Client.
The Events page is where you specify the events that
you wish to monitor and record. An event is some action
that’s occurred on the server, such as a connection being
made or broken, a stored procedure being executed, or a
batch of SQL statements being executed.
The Data Columns page has two uses. The first is to
specify what information to capture about each event.
The type of information will depend on the events that
you’re monitoring. For instance, if you’re monitoring
SQL:StmtCompleted, the Text Data column will contain
the text of the statement that was executed, and the
Integer Data column will contain the number of rows
return by the statement. The second use is to specify a
grouping for the captured information. You might want
to group all the events by connection. Without a grouping,
all events will be listed in the order that the Profiler
captured them.
The final page is the Filters page. Filters limit the data
collected by the Profiler. There are three types of filters.
Value filters allow you to specify only one value to
include in the captured information. For instance, you can
specify the Connection ID to include. Range filters allow
http://www.pinpub.com
you to specify a range that a value must fall within in
order to be included in the captured information. An
example would be the CPU filter, which allows you to
specify the minimum and/or maximum CPU usage
in milliseconds.
Include/Exclude filters allow you to specify a
discrete list of values that the captured data must have, or
must not have, to be included in the Trace. Application
Name is an example of this type of filter. By default, the
Application Name filter will be configured to exclude
applications that have registered a name beginning with
“SQL Server Profiler.” I like to include SQLAgent to the
list of excluded applications by changing the exclude
option to “SQL Server Profiler%; SQLAgent%”.
Running a Trace
Once the Trace is defined, you can start it by selecting the
Start Traces toolbar button and selecting your Trace from
the list. After the Trace has been started, you’ll see a
window with two panes. The top pane contains a list of
all the recorded events; the bottom pane contains a copy
of the data return in the Text Data column.
Configuring VFP
On the VFP side, we need very little—just a database
container, a connection, and a remote view. You can use
the following VFP commands to create everything:
*-- The database container
CREATE DATABASE Mystery
SET DATABASE TO Mystery
Figure 1. The Events page of the Trace Properties dialog box.
http://www.pinpub.com
*-- The connection
CREATE CONNECTION cnMystery ;
CONNSTRING "Driver=SQL Server;Server=merlin;" + ;
Database=pubs;Trusted_Connection=Yes"
*-- The remote view
CREATE SQL VIEW v_authors REMOTE CONNECTION cnMystery ;
AS ;
SELECT * FROM authors
The connection that I’ve created here is called a
“DNSless” connection. I’ve supplied all the parameters
that ODBC requires to establish the connection, without
using the ODBC Administrator to create a DSN.
Configuring SQL Server Profiler
Setting up the Profiler requires that we configure and start
a Trace. Create a new Trace by selecting the New Trace
toolbar button. The Trace Properties dialog box will
appear. Create a Private Trace named Mystery. On the
Events page, select the following events: SP:Completed,
RPC:Completed, and SQL:StmtCompleted (see Figure 1).
On the Data Columns page, keep the columns that were
selected by default. On the Filters page, add ‘Microsoft%’
to the Include option for the Application Name filter (see
Figure 2).
Running the experiment
Start the filter if it didn’t start automatically. Switch to
VFP, and execute this command:
OPEN DATABASE Mystery
USE v_authors NODATA
USE
Figure 2. The Filters page of the Trace Properties dialog box.
FoxTalk April 1999 15
 You’ll only need to open the database if it’s not
already open. Then switch back to the Profiler and stop
the Trace.
The results
Figure 3 shows the results from my computer. I’ve
expanded the event of interest; it’s the first
RPC:Completed event. The Text Data column shows
the batch that was sent to SQL Server. It’s a call to the
sp_prepare system stored procedure.
If you were to look up sp_prepare in the SQL Server 7.0
Books Online (BOL), you’d find it mentioned in two places.
The first is with a discussion of NT Performance Monitor
objects and counters. The second is with the system stored
procedures—at the bottom. As it turns out, sp_prepare isn’t
well-documented. It’s meant to be called from OLEDB
Providers and ODBC drivers only.
I’m still not satisfied. I still don’t understand how
VFP is getting the information that it needs to construct
the result set. There’s one more tool that might help with
the missing pieces: Dynamic ODBC Tracing.
Dynamic ODBC Tracing
The ODBC Manager has the ability to record all ODBC
function calls. All calls made between the application and
the ODBC Manager or between the ODBC Manager and
the ODBC Driver are captured and recorded in a log file.
To enable ODBC Tracing, open the ODBC
Administrator. The ODBC Administrator must remain
open while the Tracing occurs. On the Tracing tab, select
the name and location for the log file. After you’ve
selected a file to capture the ODBC calls, click the Start
Tracing Now button. Any ODBC Function call made by an
application or the ODBC Manager will now be logged
into the file you previously specified.
To disable ODBC Tracing, click the Stop Tracing Now
button on the Tracing tab of the ODBC Administrator.
Once the Tracing has been disabled, you’re free to close
the ODBC Administrator.
Experiment number two
This time I re-ran the same VFP commands as before, but I
Figure 4. It’s obvious that the output from ODBC Tracing was
meant for C/C++ programmers. This is the section of the Trace file
where VFP is calling SQLPrepare().
Figure 5. VFP queries ODBC for the number of columns in the
result set. SQLNumResultCols() returns 10.
16 FoxTalk April 1999
Figure 3. The results of a SQL Server Profiler Trace.
started the Dynamic ODBC Tracing instead of the SQL
Server Profiler (see Figure 4).
Finally, the answer
Figure 4 contains the call that VFP makes to prepare the
SQL statement. I looked up SQLPrepare() in the ODBC
Programmers Reference and found the following line:
“Once the application prepares a statement, it can request
information about the format of the result set.” This is
what VFP does. After the call to SQLPrepare(), VFP
queries ODBC for the number of columns that exist in the
result set (see Figure 5). Then VFP makes a series of calls
to SQLColAttributes() to gather information about the
column like the datatype, size, precision and scale (if
applicable), null support, and name (see Figure 6).
Conclusion
The goal of this article was twofold. First, I wanted to
demonstrate two of my favorite tools that most
developers either don’t understand or don’t even know
about: ODBC Tracing and the SQL Server Profiler. I’ve
found both to be very helpful in determining the cause
of problems when things look right in VFP but I don’t
get the correct results from SQL Server. Second, I really
was curious how VFP was retrieving the necessary
information from SQL Server to create an empty view.
You can use these same tools to help troubleshoot
problems you run into when connecting VFP and
SQL Server. ▲
Michael Levy is a consultant with ISResearch, Inc., a Microsoft Solution
Provider and Certified Technical Education Center. He’s also a Microsoft
Certified Solution Developer and a Microsoft Certified Trainer. Michael
specializes in using Visual Studio and SQL Server to solve business
problems. mlevy@isresearch.com.
Figure 6. An example of VFP querying ODBC for
column attributes.
http://www.pinpub.com

The Basics of Buffering
Jim Booth
In FoxPro 2.x, we spent a lot of effort to preserve record values
so we could offer the users an opportunity to revert their
edits. VFP gives us a mechanism to make this issue easier to
handle. Data buffering is the tool to use for this. In this article
and the next fewin this series, Jim examines the nuances of
data buffering and the other ancillary requirements in VFP.
This month, he covers the basics of data buffering.
T
HE first question is, “Should I use data buffering at
all, or should I just keep on going with SCATTER
and GATHER to handle the problem?” Well, the
answer isn’t simple. SCATTER and GATHER require that
the variables or array be scoped properly so that they’re
visible to all of the objects that need to access them. Since
variables are, by default, privately scoped (that is, they’re
destroyed when the routine that created them terminates),
we have a problem.
If, in a form method, I SCATTER MEMVAR, those
variables go out of scope as soon as the form’s method
ends, unless I declare all of the variables as public before
doing the SCATTER. Declaring variables public has its
own set of problems that are beyond the scope of this
article, so let’s just agree that we don’t want to do that
unless there’s absolutely no other way to do what we
want to do.
With the ability of VFP’s controls to be bound to data,
it makes sense to have the data available during the
creation of the control. The creation sequence is such that
the Data Environment (DE) of a form is created before any
of the controls are created. This allows the DE to open the
data cursors before the controls try to bind to their
controlsources. If we bind the controls directly to the
fields in the cursors, this all works well; however, if we’re
binding to memory variables, we must ensure that those
variables exist at the time the controls are created.
This variable creation could be done in the form’s
Load event (which fires before the controls are created) by
declaring the variables as public and then scattering to
them. Oops, there goes that public stuff again (where’s a
vampire slayer when you need one?).
Data buffering gives us the best of both worlds—
we can bind directly to fields, and we can control
the updating or reverting of the record on disk. By
binding directly to fields, the whole variable scoping
problem disappears.
Is there ever a situation where you might not want
buffering? Yes. If one of the requirements is that edits are
http://www.pinpub.com
What’s Really Inside FoxTalk
6.0
committed immediately and irrevocably, then “no
buffering” is the way to go. Additionally, if you have
a table that’s read-only, then you can set buffering
to “None.”
What is data buffering?
In FoxPro 2.x, when we issued our GETs against fields in
a table, we said we were doing direct edits. We called
them direct because we assumed that the fields in the
table were being directly edited. We had no control over
the updating process. In fact, FoxPro 2.x was doing the
edit in a memory buffer of the record, which would later
be used to update the table. In FoxPro 2.x, we had no
control over the buffer—it would be written when FoxPro
got around to it, and there was no way we could stop it
from happening.
VFP’s data buffering mechanism gives us control
over that edit buffer. It allows us, when buffering is on,
to control when and if the buffer gets committed to disk.
Data buffering is simply a technology that makes it easier
for us to do what we were doing before.
VFP’s data buffering adds some functionality to
the process. With the use of functions like OldVal() and
CurVal(), we can find out what the buffer started with
for values and find out what’s currently on disk,
respectively. There are also a number of other functions
that enhance the data buffering in VFP as we go along
on this exploration.
Why five buffering modes?
There are five buffer modes. These are:
• None (1)
• Pessimistic Row (2)
• Optimistic Row (3)
• Pessimistic Table (4)
• Optimistic Table (5)
None
The None (1) setting disables the data buffering and
causes VFP to act just like FoxPro 2.x in regards to
editing data.
Optimistic
With optimistic buffering, VFP doesn’t lock any records
when editing begins. Instead, when an attempt to update
the table occurs, VFP checks to see whether the record it’s
FoxTalk April 1999 17
updating is the same as what the buffer started with. If
they’re the same, the update is done; if not, then the
update isn’t done (more on this later).
Pessimistic
With pessimistic buffering, VFP first attempts to lock the
record when an edit begins. Then, if it can get the lock, the
edit is allowed. If VFP can’t get the lock, then an error
condition (“Record is in use by another”) occurs, and the
edit is rejected.
Row
Row buffering allows only one record to be dirty in the
buffer at a time. Dirty, as used here, means that the record
has been edited in the buffer. An attempt to move the
record pointer in a cursor that has row buffering on will
cause VFP to implicitly attempt to update the table.
Table
Table buffering allows multiple records to be dirty in a
cursor’s buffer. Moving the record pointer doesn’t have
any implicit updating activity.
By combining the optimistic/pessimistic with the
Row/Table, you get four separate buffer modes in
addition to the None setting.
What’s that sixth buffering mode?
In the BufferModeOverride property for a cursor in a DE,
you’ll see six choices. The additional choice is “Use the
form setting,” which causes VFP to use the BufferMode
setting for the form and to decide on Table or Row
buffering based on the type of control being used (more
on this later).
Which one has the right stuff?
First, let’s look at optimistic vs. pessimistic. Pessimistic
locks records on the server; it also ensures the right to
write before it allows the edit to begin. These seem like
some very valid reasons to prefer pessimistic buffering.
Well, before we draw any conclusions, let’s look at the
downside of pessimistic buffering.
Pessimistic buffering locks the record when the edit
begins and holds that lock until the update occurs. This
means that if Mary starts an edit and then goes to lunch,
no one can work on the record that Mary is editing.
Pessimistic uses locks at the network server, which
consume server resources. Often the network server has a
limited number of simultaneous locks available, and if
your number of users grows, you could end up with
network errors when the pessimistic buffering tries to get
a lock and can’t.
Optimistic buffering doesn’t secure locks until the
update occurs. It gets the lock, does the update, and
releases the lock. These locks are held briefly. The
downside is that optimistic buffering might fail to update
18 FoxTalk April 1999
because of an update conflict, while pessimistic buffering
won’t. Isn’t that enough reason to prefer pessimistic?
No. Using optimistic buffering, you can secure your own
lock when an edit begins and release the lock when you
want to, so optimistic buffering can provide the same
functionality as pessimistic. The problem as I see it is that
pessimistic buffering gives no choice or control over what
to lock and when (it happens by magic), while optimistic
gives me that control. I hate magic! So, my preference is
optimistic buffering for everything. If I need to ensure the
writing of data, I’ll handle that in my code.
How about Row vs. Table? The same reasoning
applied to optimistic vs. pessimistic can be used here.
Row buffering allows only one record to be dirty at a
time, and it does a magic update if the record pointer
moves. Table buffering does no magic stuff at all; because
it allows multiple records to be dirty at once, it doesn’t
need to update when the pointer moves. You can restrict
the editing to only one record at a time through the user
interface; don’t let them move to another record while an
edit is in progress.
Why is the implicit update a problem? VFP is object-
oriented, and as such we create classes that have specific
behavior. We try to make these classes generic so they can
be used in multiple places. If you create a form, use Row
buffering, and then at a later time add another control to
the form based on a class that looks something up in a
cursor, you might very well introduce an unexpected
automatic update of the buffer. Not only can this situation
be created, it would be a bear to try to debug. With Table
buffering, there’s no magic going on; therefore, the issue
here becomes a non-issue.
So, then, my opinion is to use optimistic Table
buffering all the time. If I need single-record editing, I
code it. If I need ensured writes (pessimistic locks), I
code for it.
How and where do I set the buffer mode?
You have a variety of ways to set buffer modes.
They’re the form’s BufferMode property, the
cursor’s BufferModeOverride property, and the
CursorSetProp() function.
Form’s BufferMode property
The BufferMode property of a form gives you three
choices for setting the buffer mode: 0-None, 1-Pessimistic,
and 2-Optimistic, respectively. The row or table option
of the buffer mode is handled by the control that the
table is bound to; if it’s bound to a grid, Table buffering is
used, and if it’s bound to another control, Row buffering
is used.
Cursor’s BufferModeOverride property
The BufferModeOverride property for a cursor in a DE
allows six settings. The options are 0-None, 1-Use form
http://www.pinpub.com
setting, 2-Pessimistic Row, 3-Optimistic Row,
4-Pessimistic Table, and 5-Optimistic Table. The
BufferModeOverride should be set for every cursor
in the DE if you want a setting other than 1-Use form
setting (the default).
CursorSetProp()
The CursorSetProp() function can be used to
programmatically set the buffer mode. The
CursorSetProp() function has the following syntax:
CURSORSETPROP(cProperty [, eExpression] ;
[, cTableAlias | nWorkArea])
To set buffering modes, the first argument is
“BUFFERING”, the second is the number of the buffer
mode desired (as listed in the BufferModeOverride
section), and the last is the alias name of the cursor in
which you want to set the buffer mode. For example, if I
wanted to set optimistic Table buffering in a cursor with
the alias of Customer, I’d do the following:
CursorSetProp("buffering", 5, "Customer")
In order to use CursorSetProp() to set a buffering
mode, the SET MULTILOCKS option must be ON
(it’s off by default unless you’ve changed this in the
Tools|Options dialog box). Setting Buffer modes in a form
does require explicit setting of the multilocks option, as
Third-Party Reporting . . .
Continued from page 13
different areas in the catchment (for example, build a
factory on undeveloped parkland) using a geographic
information system (GIS)—ArcView. FoxPro then reads
the geographic data as well as some rainfall data and
produces input files for a numerical model—SWMM. The
numerical model predicts how full each of the segments
of pipe in the drainage network will run at each time step
and outputs its results to a text file.
In the reporting phase, FoxPro reads the text file and
sends the data to the GIS. The GIS produces a standard
.WMF file for each time step in which the pipe segments
are colored and proportioned relative to the amount of
water flowing through them at that time. Finally, a
PowerPoint presentation is built from FoxPro using OLE
Automation so that each of the time steps can be
displayed in sequence. This gives the effect of viewing the
state of the network as the design storm progresses.
Displaying the data in this way allows the users to
quickly see the effects of their design decisions. A sample
of the PowerPoint presentation produced is included in
http://www.pinpub.com
the form will automatically set the multilocks for you.
How do you control the updates?
The updating process is controlled through two functions,
TableUpdate() and TableRevert(). The former does an
update of the record, and the latter undoes the edits and
reverts the buffer back to what’s currently in the record.
Next month, we’ll investigate these two functions in
more depth.
Conclusion
“We can do this the hard way or we can do this the
easy way.” Data buffering is the easy way, once you
understand how it works. It takes less code to accomplish
the same results as the FoxPro 2.x methodology, and it
allows for the exploitation of the data binding capabilities
of the VFP controls. There are a lot of choices related to
data buffering. A careful examination of each of these
choices will go a long way in simplifying the decisions. ▲
Jim Booth is a Visual FoxPro developer and trainer. He has spoken at
FoxPro conferences in North America and Europe. Jim has been a
recipient of the Microsoft Most Valuable Professional Award every year
since it was first presented in 1993. He is coauthor of Effective Techniques
for Application Development and Visual FoxPro 3 Unleashed and is
contributing author for Special Edition Using Visual FoxPro 6.0. Visit his
Web site at www.jamesbooth.com. 203-758-6942,
jbooth@jamesbooth.com.
the Subscriber Downloads.
Conclusion
FoxPro has a rich and powerful set of analysis and
reporting features, but it isn’t all things to all people.
The smartest way to develop solutions is to use the
appropriate tool for the task. If your application
requires fast data access and a good GUI development
environment, then by all means use FoxPro exclusively.
If there are more specialized requirements, then make
use of the specialized tools available and you’ll save
yourself a whole heap of heartache.
This is the last installment in the analysis and
reporting series of this column. Next month, I’m going
to discuss some techniques for matching records,
including phonetic matching, address standardization,
and other techniques. ▲
04COATSC.ZIP at www.pinpub.com/foxtalk
Andrew Coates is a director of Civil Solutions, a PC development
consultancy in the Olympic City, Sydney, Australia. Andrew specializes
in PC database applications, particularly in integrating components
and visualizing spatial data. a.coates@civilsolutions.com.au.
FoxTalk April 1999 19

Buffering: The
Transaction Slayer
“A Discussion of Transactions and Buffering Modes
in the Context of the Construction of a Multi-layer
Commission Calculation Class”
Paul Maskens and Andy Kramek
This month, Paul and Andy look at table buffering and
transactions, based on the commission update problem from
last month (see “Curses and Recurses”). If you’re not up to
speed with the basics behind buffering, see Jim Booth’s article
on buffering on page 17.
Paul: Last month, we created a class to calculate the
commissions. Having looked at some of the issues in
saving that data, I think that was the easy part. Now I
know why you tried to run away. The solution seems
slightly easier in VFP 5 than in VFP 3, but should we talk
about both?
Andy: I guess we should; we can’t afford to assume that
every reader has gone to VFP 5 or VFP 6. As far as this
problem is concerned, we’re only going to use the basic
TABLEUPDATE(), which is common to versions 3, 5,
and 6. Essentially, all we need to talk about is the
difference in the behavior of TABLEUPDATE(); the
additional functionality is worth having, but we don’t
need it in this case.
Paul: Well, here’s what I think happens. First, you have
to update some records <g>. Then, when you issue
TABLEUPDATE( .T., .F., ‘mytable’ ) in VFP 3, the updates
are attempted. But FoxPro stops updating the table from
the buffer as soon as the first error occurs.
If you use VFP version 5, then you can use
TABLEUPDATE( 2, .F., ‘mytable’, laErrors ), and FoxPro
will again attempt to update all buffered rows, continuing
after any errors and placing record numbers for each
record that can’t be updated in the fourth parameter into
the array passed.
Andy: While that’s useful, we don’t need to use it because,
in this case, any failure means we have to recalculate the
entire commission chain. So we just need to roll back,
20 FoxTalk April 1999
The Kit Box FoxTalk
6.0
recalculate, and try again. But why are you assuming
table buffering?
Paul: I just assumed that we were going to use optimistic
table buffering because I couldn’t see how to make any
other buffering system work in this case. After all, we’re
going to be amending multiple records when we walk the
salesman hierarchy calculating those commissions.
Andy: I don’t agree. Remember, the transaction is holding
the locks, so we can use an explicit TABLEUPDATE() after
each set of values from the array is copied to the record.
It doesn’t matter whether the buffering is table or row
buffering, because we’re always updating the row as we
get to it.
Paul: Oh, I see. That makes it simpler. Before we get
started, I’d like to clear up a misunderstanding over
TABLEUPDATE() that I’ve seen in live code. It doesn’t
help when the VFP Help file uses =TABLEUPDATE(.T.)
in its example. The return value isn’t tested, and it’s
assumed that the update will succeed. Updating the name
field in one record is hardly a real-world example, let
alone good programming practice—that function return
result is provided for a reason!
When a TABLEUPDATE() returns .F., that means
the update didn’t complete successfully. Code using
TABLEUPDATE() has to check that result or risk leaving
unsaved buffered changes. In VFP 3, those changes are
detected when the table is closed, forcing an error. In VFP
5, those changes are simply lost.
Andy: That’s the correct behavior. No other sensible
database management system would consider closing a
table with uncommitted changes to be an error; it would
simply assume the changes aren’t required.
http://www.pinpub.com
Paul: Okay, now, with that out of the way, I agree that
we need a transaction so that all the changes can be
undone. Am I right in assuming it’s because each
TABLEUPDATE() will save some data from the buffer,
leaving that record marked as not updated any more?
What I need is to be able to revert the changes after
they’ve been saved—which TABLEREVERT() won’t do.
Andy: Correct, you can’t use TABLEREVERT() at that
point because you’ve done a TABLEUPDATE() that’s
succeeded. Provided they all succeed, there’s no problem.
Paul: Well, there’s a little problem with transactions, isn’t
there? They can only be nested to five levels! Just where
are those transactions going to be started and ended when
saving the data? If the data needs to be updated more
than five levels up the hierarchy, won’t we run out of
transaction levels?
Andy: It’s a reasonable question, but that’s not how it
works. Look at the code <g>. I’ve only used one
transaction around the whole hierarchical update,
because we’re interested in an all-or-nothing update.
Paul: So the BEGIN TRANSACTION in the UpdResult()
method is the only one that’s needed? That seems simple.
Here’s the relevant code from last month:
*** Method to update the result table
*** Returns .T./.F.
PROTECTED FUNCTION UpdResult()
LOCAL llOk, lnRows, lnCnt
PRIVATE pnResPk, pnOriCnt, pnOriVal, pnNewCnt, ;
pnNewVal
*** Start a transaction
llOk = .T.
BEGIN TRANSACTION
lnRows = ALEN( This.aStack, 1 )
FOR lnCnt = 1 TO lnRows
STORE 0 TO pnResPk, pnOriCnt, pnOriVal, ;
pnNewCnt, pnNewVal
This.Pop( lnCnt )
*** Find results record
llOK = This.FindRec( pnResPk, 'salesres', ;
'respk' )
IF ! llOK
EXIT
ENDIF
*** Check that values are unchanged
IF salesres.rescount = pnOriCnt ;
AND salesres.resvalue = pnOriVal
*** Replace data
REPLACE rescount WITH pnNewCnt, ;
resvalue WITH pnNewVal IN salesres
*** Commit changes
llOk = TABLEUPDATE( .F., .F., 'salesres' )
IF ! llOk
EXIT
ENDIF
ELSE
*** Exit with error if not
llOk = .F.
EXIT
ENDIF
NEXT
IF llOk
END TRANSACTION
ELSE
ROLLBACK
ENDIF
*** Return status
http://www.pinpub.com
RETURN llOK
ENDFUNC
Andy: It is. The strategy is to start a transaction, and then,
for each row in the stack, retrieve the information we
saved, find the appropriate record, and use a normal
FoxPro REPLACE to update the record. Then explicitly
use a TABLEUPDATE() to try to save the change to that
record, and log the result of that update attempt.
As soon as an error condition occurs inside that
loop, the status flag goes to false, the loop is exited
immediately, and the transaction will be rolled back. The
status flag is set to false if the record can’t be located in
the results table, if the record is located but the data in the
record has changed since we did the calculation, or if the
update of the table after the replace fails.
Paul: So you’re trapping errors at three levels: If another
user deleted the salesman’s record, if another user
updates the same record before we try the replace, and,
finally, if another user updates the same record while
we’re updating the record. We aren’t using buffering
except for the very short time where we’re trying to write
the update.
Andy: Right. I know it seems counterintuitive, but
buffering is the last thing that we want. We need to
process as little as possible if there’s an error, to make
the overall saving process as fast as possible. We are, in
effect, using the stack as a buffer, to hold the changes we
want to apply.
Paul: So this updating process is now effectively atomic.
Instead of just calling the UpdComm() method, we do
need to test that return result and handle a failure of that
in some way. Here’s the main routine again from last
month; I suppose this isn’t the right place to handle the
retry, because we need to recalculate:
*** Exposed Main control function
*** Input parameters are the starting ID and
*** the base value
*** Returns Success/Failure
FUNCTION UpdComm( tnStmPK, tnValue)
LOCAL lnNextID, llRetVal, lnCommDue
*** Clear the stack
DIMENSION This.aStack[1, 5]
STORE 0 TO This.aStack
*** Check parameters
IF EMPTY( tnStmPK ) OR EMPTY( tnValue )
*** Must pass a PK and value
RETURN .F.
ELSE
lnNextID = tnStmPK
ENDIF
*** Start the Main loop here
llRetVal = .T.
DO WHILE ! EMPTY( lnNextID )
*** Find the record in SaleTeam
llRetVal = This.FindRec( lnNextID, 'saleteam', ;
'stmpk' )
IF ! llRetVal
*** PK doesn't exist in SaleTeam
EXIT
ENDIF
*** Get Next ID to use from SaleTeam
FoxTalk April 1999 21
 lnNextID = saleteam.stm2FKmgr
*** Now find the correct result record
llRetVal = This.FindRec( saleteam.stmpk, ;
'salesres', 'resstmfk' )
IF ! llRetVal
*** PK doesn't exist in Results
EXIT
ENDIF
*** Calculate the commission payable
lnCommDue = This.CalcComm( saleteam.stmlevel, ;
tnValue )
*** Push the data to the stack
This.Push( lnCommDue )
ENDDO
*** If no failures along the way
IF llRetVal
llRetVal = This.UpdResult()
ENDIF
RETURN llRetVal
ENDFUNC
Andy: Right. The application is going to have to handle a
failure in UpdComm(). That responsibility belongs in the
application. I don’t think it even belongs in the instance.
In answering the must/should/could question, the code
could be there, which suggests a subclass. But the
handling of those sorts of errors must be application-
specific, so it belongs in the application; otherwise, you
have one subclass per application, which is pointless.
Paul: A simple approach would be to have a loop that calls
UpdComm() a number of times, retrying until either it
succeeds or the user runs out of patience, or you’ve
performed a set number of retries.
Andy: Sounds about right. It’s not our problem, though, is
it? As you say, it’s an application-level SEP.
Paul: I do have another really sneaky solution that solves
the multiple user update problem.
Andy: Go on then, I’m sure I’ll like it.
Paul: Do it single user.
Andy: Okay, I like it. What on earth are you talking about?
Paul: If you don’t need the changes in real time, then write
the data to make the changes into a queue file. Service that
queue with a program that runs continuously, taking the
oldest change and applying it to the table (marking it
applied, of course). Since it’s now single user (there’s only
one daemon), there’s no update conflict to resolve.
I actually thought of it before looking at Oracle, but
it’s a “new feature” in Oracle8. They claim it’s a
particularly good way to improve the speed of data entry.
Andy: All we need is the Primary Key and an increment
for the count and the value. We don’t need the results
themselves, only the data to perform the calculation. In
fact, we only need the value to add; we’re always going to
increment by one.
22 FoxTalk April 1999
Paul: It actually could improve performance. Think about
it for a moment. Do you have 12 data entry operators, all
running the same code to make the changes and attempt
to resolve the conflicts? Or is it better to serialize the
updates and reduce the contention?
Andy: Yes, your update will never fail. Oh, you’d need a
date/time stamp, of course.
Paul: Why? If all that’s being done is increment and
addition, it doesn’t really matter if the changes of two
users are interleaved in the queue—the end result is
the same.
Andy: Agreed, unless it became important to apply
updates only for a particular period. You might want to
process updates only until the 31st of the month or
something; I’d add the timestamp on principle. I’d prefer
to have it there just in case rather than have to modify the
system and put it in later.
Paul: I can see you might want it for recovery, too. Perhaps
to reapply all updates for the week after restoring from
the backup tape.
Andy: It’s the sort of thing that will cost you virtually
nothing to do, but you might find that there are
thousands of uses for it—management information, for
example. After all, it would be a tiny file—something you
could keep for ages.
Paul: If we use queueing, is all of this is irrelevant? We
could just write the information straight into the queue
from the stack, instead of using buffering or transactions
in this process.
Andy: You mean APPEND FROM ARRAY THIS.aStack?
It’s just as well that I didn’t acquiesce to your insistence
on using a true stack; you’d have to pop off that stack into
another array first.
Paul: Maybe so, but that was more by luck than
judgment <g>.
What actually seemed to be quite a difficult problem
has actually proven to be rather simple, and we have
two solutions: one using an explicit tableupdate and a
transaction, and one using a queue. ▲
Paul Maskens is a VFP specialist and FoxPro MVP who works as
programming manager for Euphony Communications Ltd. He’s based in
Oxford, England. pmaskens@compuserve.com.
Andy Kramek is an old FoxPro developer, FoxPro MVP, and independent
contractor and occasional author based in Birmingham, England, who
now works in the U.S. 104074.3130@compuserve.com.
http://www.pinpub.com
Downloads April Subscriber Downloads
• 04COATSC.ZIP—Source code described in Andrew Coates’
article, “Third-Party Reporting Tools.”
Extended Articles
• 04DONNIC.HTM—“Best Practices: Seeing Patterns: Chain of
Responsibility.” This month, the Best Practices column
continues the “Seeing Patterns” series, which discusses
common object-oriented design patterns. The purpose of
this series of columns is to describe each pattern briefly and
then demonstrate examples of the patterns in Visual FoxPro
applications. The focus of this column is on the Chain of
Responsibility pattern, which allows for passing messages
through various objects, giving each object an opportunity
to act on the message.
• 04DONNIC.ZIP—Source code described in Jeff Donnici’s
Editorial: Microsoft . . .
Continued from page 3
In fact, news of Microsoft’s recent reorganization,
where the company was being aligned across customer
groups instead of products, was seen by some as a
defense against such a breakup plan, since the breakup
would presumably be made more difficult after the
reorganization.
Of course, both of these were wrong.
Microsoft won’t be divided into pieces across product
lines—one company responsible for Windows, another for
developer tools, a third for edutainment products. Nor
will the company be split into functional lines, such as for
business, home use, and so on. Instead, the company’s
breakup will be divided into geographic areas, just like
Standard Oil was a century ago. Imagine: Microsoft New
York. Microsoft Texas. Microsoft L.A. Fascinating, eh?
But fascination doesn’t do much for you when
you’re trying to deliver an application. What does this
mean to you?
First, you’ll no longer have to listen to your customers
whine about Bill Gates being the richest man in the world
(“Gee, I’d sure like to be in his shoes.”). He will become,
as Jay Leno presciently joked recently, the world’s five
richest men.
http://www.pinpub.com
article, “Seeing Patterns: Chain of Responsibility.”
• 04HENNIG.HTM—“Reusable Tools: Building a Builder
Builder.” Creating builders is a snap using enhancements
to Ken Levy’s BuilderD technology. Doug Hennig shows
you how.
• 04DHENSC.ZIP—Source code described in Doug Hennig’s
article, “Building a Builder Builder.”
• 04HENTZE.HTM—“Visual Basic for Dataheads: A Command
and Function Summary—Part 2.” In Part 1 of this series,
you got a glimpse of the language through a summary
of functions. This month, Whil Hentzen covers the logic
structures and commonly used commands in Visual Basic
and compares them to their counterparts in VFP.
Second, you’ll soon see a flurry of competitive
mechanisms arise as each of these companies struggles for
market share. I predict that by the summer, you’ll be able
to buy Windows via kiosks on every street corner, and
you’ll be able to “pay as you go”—buying two weeks of
Windows at a time, for example.
You think I’m joking? Knowledge Base article
#216641 (Title: “Computer Hangs After 49.7 Days,”
Symptom: “After 49.7 days of continuous operation, your
Windows 95-based computer might stop responding.”)
indicates that a regular fill-up of Windows might be a
good idea. I wonder if, when you pull up to the full-
service kiosk, a uniformed attendant will wash your
monitor’s screen for you?
You’ll also probably see a few name changes.
Microsoft New Jersey will become something goofy, like
ExxonSoft. Microsoft Kentucky will rename its flagship
product “Microsoft Winders.” I don’t know any of this for
a fact—but events like these are bound to happen.
Finally, you’ll be able to buy stock in companies like
Microsoft Georgia, Microsoft New York, Microsoft Ohio,
and Microsoft Illinois, thus allowing you to diversify your
portfolio. And you can stop complaining about the tepid
pace of government action, because this will all become
possible as of, not coincidentally, April 1, 1999. I know I
can’t wait. ▲
FoxTalk April 1999 23
 FoxTalk Subscription Information: Editor Whil Hentzen; Publisher Robert Williford;
Vice President/General Manager Connie Austin;
1-800-788-1900 or http://www.pinpub.com Managing Editor Heidi Frost; Copy Editor Farion Grove

Subscription rates: Direct all editorial, advertising, or subscription-

related questions to Pinnacle Publishing, Inc.:
United States: One year (12 issues): $179; two years (24 issues): $259
1-800-788-1900 or 770-565-1763
Canada:* One year: $194; two years: $289
Fax: 770-565-8232
Other:* One year: $199; two years: $299
Pinnacle Publishing, Inc.
Single issue rate: $17.50 ($20 in Canada; $22.50 outside North America)* PO Box 72255
European newsletter orders: Australian newsletter orders: Marietta, GA 30007-2255
Tomalin Associates, Unit 22, The Bardfield Centre, Ashpoint Pty., Ltd., 9 Arthur Street,
Braintree Road, Great Bardfield, Dover Heights, N.S.W. 2030, Australia. E-mail: foxtalk@pinpub.com
Essex CM7 4SL, United Kingdom. Phone: +61 2-9371-7399. Fax: +61 2-9371-0180.
Phone: +44 1371 811299. Fax: +44 1371 811283. E-mail: sales@ashpoint.com.au
Pinnacle Web Site: http://www.pinpub.com
E-mail: 100126.1003@compuserve.com. Internet: http://www.ashpoint.com.au FoxPro technical support:
* Funds must be in U.S. currency. Call Microsoft at 425-635-7191 (Windows)
or 425-635-7192 (Macintosh)

FoxTalk (ISSN 1042-6302) is published monthly (12 times per year)
by Pinnacle Publishing, Inc., 1503 Johnson Ferry Road, Suite 100,
Marietta, GA 30062. The subscription price of domestic
subscriptions is: 12 issues, $179; 24 issues, $259. POSTMASTER: Send
address changes to FoxTalk, PO Box 72255, Marietta, GA 30007-2255.
Copyright © 1999 by Pinnacle Publishing, Inc. All rights reserved. No
part of this periodical may be used or reproduced in any fashion
whatsoever (except in the case of brief quotations embodied in
critical articles and reviews) without the prior written consent of
Pinnacle Publishing, Inc. Printed in the United States of America.
Brand and product names are trademarks or registered trademarks
of their respective holders. Microsoft is a registered trademark of
Microsoft Corporation. The Fox Head logo, FoxBASE+, FoxPro, and
Visual FoxPro are registered trademarks of Microsoft Corporation.
FoxTalk is an independent publication not affiliated with Microsoft
Corporation. Microsoft Corporation is not responsible in any way for
the editorial policy or other contents of the publication.
This publication is intended as a general guide. It covers a highly
technical and complex subject and should not be used for making
decisions concerning specific products or applications. This
publication is sold as is, without warranty of any kind, either express
or implied, respecting the contents of this publication, including
but not limited to implied warranties for the publication,
performance, quality, merchantability, or fitness for any particular
purpose. Pinnacle Publishing, Inc., shall not be liable to the
purchaser or any other person or entity with respect to any liability,
loss, or damage caused or alleged to be caused directly or indirectly
by this publication. Articles published in FoxTalk reflect the views of
their authors; they may or may not reflect the view of Pinnacle
Publishing, Inc. Inclusion of advertising inserts does not constitute
an endorsement by Pinnacle Publishing, Inc. or FoxTalk.

The Subscriber Downloads portion of the FoxTalk Web site is available to paid
subscribers only. To access the files, go to www.pinpub.com/foxtalk, click on User name ginger
“Subscriber Downloads,” select the file(s) you want from this issue, and enter the
user name and password at right when prompted. Passwordd haunt
asswor
or

24 FoxTalk April 1999 http://www.pinpub.com