The LA Fox Developer Newsletter

June 2000

ADO Jumpstart for Microso

Visual FoxPro Developers

Part 5

John V Petersen

[Ed. Note: Reprinted with the author’s full permission. This is

the fifth installment of a multi-part article begun in February’s

LA Fox Developer.]

With the basics of hierarchical recordsets out of the way, we

can turn our attention to a more complicated, real-life example.

The following example adds several dimensions to the

recordset.

First, the Order Details table is appended to the Orders child

recordset. In this case, a new field that will in turn point to the

OrderDetails recordset, is added to the Orders recordset. The

Products table is then appended to the OrderDetails recordset

providing three levels of nesting. Appended to the Products

recordset are two tables, Categories and Suppliers. Traversing

up the hierarchy to the Orders recordset appends the Employ-

ees table.

This list illustrates the hierarchy and shows all the tables

involved as well as the nesting scheme. When creating reports

it is quite possible that you will need all of these tables. The

ability to relate tables in this fashion and the ability to display

the data in a user interface or a report have always been true

powers of Visual FoxPro. Before ADO, attempting all this work

outside Visual FoxPro was extremely difficult, sometimes

bordering on the impossible.

Customers

Orders

OrderDetails

Products

Categories

Suppliers

Employees

EmployeeTerritories

Territories

Region

Shippers

The following is the Shape syntax to create the hierarchical

recordset:

SHAPE (SELECT * FROM "dbo"."Customers") AS Customers

APPEND (( SHAPE (SELECT * FROM “dbo”.”Orders”} AS Orders

APPEND (( SHAPE (SELECT * FROM “dbo”.”Order Details”) AS

OrderDetails APPEND (( SHAPE (SELECT * FROM “dbo”.”Products”}

AS Products APPEND ((SELECT * FROM “dbo”.”Categories”} AS

(Con’t, page 4)

Undocumented (Con’t from page 1)

can add it to your default menu.

FOXDOC

This command brings up the Getfile() dialog. If you select a file,

the _foxdoc memory variable gets set to that file. This predates

the Documenting wizard and originated from Walter J.

Kennamer’s Snap FoxPro docu mentor prior to Microsoft’s

purchase of FoxPro.

FOXGEN

This command looks for FOXGEN.COM, similar to how

FOXVIEW looks for FOXVIEW.COM.

I just renamed a batch file, renamed it to FOXGEN.COM and

placed it in the VFP6 home directory. VFP ran it!

I’m reaching here, but wasn’t this associated with the Fox

Template language? I remember creating a form design template

and proudly launching it into shareware in 1988 via FidoNET?.

— JohnKoziol

FOXGRAPH

This command brings up the Getfile() dialog, looking for

FOXGRAPH.EXE. Unless, of course, you have something

named FOXGRAPH.EXE in your home directory. Then VFP runs

it. If you select a different file, VFP throws up an error message,

but sets the _foxgraph memory variable to that file anyway.

FOXVIEW

This command looks for FOXVIEW.COM, similar to how

PKXARC used to look for PKXARC.COM. I just renamed a

batch file, renamed it to FOXVIEW.COM and placed it in the

VFP6 home directory. VFP ran it!

ACCESSO

This was my favorite undocumented function, until the latest

HackersGuide listed it.

One of my favorite FoxPro trivia questions went like this: What

function in Foxpro (and VFP) always returned zero no matter

what? I got around to telling Tamar and Ted this question during

one of the Devcons and one of’em remembered...

This was an odd pair with LogOut. Access() determined what

level of security one had when using the dBaselll+ LAN Pack.

Return values were between 1 and 8. Higher numbers meant a

higher level of access.

CALLØ

This was added for dBaselV compatibility. I have no idea what

CALLO provided over the dBaselll+ keyword CALL. CALL, I

believe, still works but CALL() does either nothing or generates

an error, depending on how you “call” it. The latest

HackersGuide documented this one...

Just guessing: maybe CALLO returns the value returned by the

call?

(Con’t, page 4)

Page 3