The LA Fox Developer Newsletter

March 1998

Give the Database Container

a Second Look

by Steve Sawyer

It surprises me how many developers are working on VFP

applications, but are spurning use of the database container.

Giving up the database container gives up some very powerful

features:

*

Transactions

*

Rules

*

Triggers

*

Field Captions

*

Field DisplayClasses

*

Default field values

*

Views

*Stored Procedures

Many folks have expressed lack of confidence in the Referential

Integrity code created by the VFP RI Builder. I’ve been using

this code for about 2 years now, and it wasn’t until a couple of

weeks ago that I personally encountered a bug in this code.

This bug didn’t show up until my error handler had to trap a

failed trigger error, and turned out to be very easily corrected.

if you're one of those that is uncertain whether tu to use the

code, I encourage you to generate RI code for a database you’re

working on. Establish a breakpoint for a change in PROGRAMO

in the watch window, and browse and edit one of the tables,

deliberately causing a failed trigger. Step through the RI code as

it executes. If you take the time to do this, and examine the

various variables that each RI function establishes, you’ll quickly

see that this code is doing almost exactly what you’d do in your

own code to enforce these kinds of integrity rules.

Even if you choose to shun the RI builder, note that the list

above does. not mention the RI Builder code as one of the

benefits of using the database container. You can still write your

own RI code, if you prefer, but you’ll still need the database

container to establish triggers to call your own code, and there

is no better repository for this code than the stored procedures

in the DBC.

The database container represents a set of “metadata”, or “data

about data” that resides in the system. The DBC provides most

of the information needed to completely re-construct the data-

base. The information that the DBC does not provide can be

made part of any database system you’re working with, provided

that you make the decision to use a database container instead

of free tables.

One very important benefit that I failed to enumerate above, is

the ability to extend the database container, establishing

properties for tables, fields, relations etc. that the DBC does not

provide natively. Any scheme for providing extended database

properties will most likely require use of the DBC. This avoids

having to duplicate those properties that are contained in the

DBC. Also, the DBC, through the “User” field in the .DBC table,

provides an easy link between the DBC and any table of ex-

tended properties.

Unfortunately, due to the tragic loss of Tom Rettig and the

database extension system he was working on, the only third-

party database container extension system in wide use is

known as DBCX. This system was embraced by Flash Creative

Management, and was intended to be part of the Codebook

framework. While this was not made an integral part of the

original Codebook framework, there are a whole set of

Codebook-specific extensions that work with DBCX. Stonefield

Systems Group, authors of the Stonefield Database Toolkit, use

DBCX extensively to provide sorely needed functionality to the

database container, including the ability to reconstruct database

headers and indexes.

[Ed. Note: Steve Sawyer is President of The Detroit Area

FoxPro Users Group and a frequent contributor to FoxPro

Advisor.)

Instantiated Windows (Con’t from page 5)

The INIT method of the Projlrak form receives the project name

as a parameter, then sets the form caption to this value. This

n the form a u niuque window caption. Thus,

if the user clicks the “Display Project” button again, then the

existing window is displayed.

[Ed. Note: Charlie Parker is a Senior Practice Partner with

Fowler Software Design in Eldorado Springs, CO, and a mem-

ber of The Rocky Mountain FoxPm Users Group.)

Just a Reminder.

1st Conference Price Break

Ending

The deadline for the first price break of The Second Annual

Southern California Visual FoxPro Conference is fast approach-

ing. After March 31st, the registration fee for this event will

jump from $350 to $425. Please see page 9 for the registration

form and all the details. So if you’re planning on attending, now

is the time to get your reservation in that is, if you like saving

money.

Page 6