3
|
|
3 |
|
|
The LA Fox Developer Newsletter
|
|
June
2000
|
|
ADO
Jumpstart for Microso
Visual FoxPro Developers
[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 Employees 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
|
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? |
|
Page 3
|
|
|
3 |
|