Databases Reference
In-Depth Information
FIGURE 2.22
A typical file suitable for database uploading.
important to be aware of the differences between the two events. The
Initialize
Event Occurs
after an object is loaded but before it is shown. The
Activate
event occurs when an object
becomes the active window. Conversely, the
Deactivate
event occurs when an object is no
longer the active window. When should the initialization parameters for a form be put into the
Initialize
Event subroutine, and when should they be placed in the
Activate
Event subroutine?
In most instances, it is best to initialize parameters within a form with the
Initialize
Event.
This is because the
Initialize
event is only called when the form is first loaded into memory.
The
Activate
Event can also be utilized to initialize the parameters within a form, and seemingly
will give the same effect. The difference is that every time the form loses focus and is then given
focus again (usually by clicking on the form or an element within it), the code in the
Activate
Event subroutine will be run again. This will cause the form to be reset to its default settings if it
should lose and regain focus within the application. In some circumstances, this may be desirable
behavior, but in most, it will not.
2.13
CREATING DATABASE-“FRIENDLY” FILES
Now that it has been shown how to store files in a manner that can be dealt with on the local level,
it is time to discuss how to format files such that they can be readily exported to a database. Files
that are “database friendly” tend to be in a flat format. What this means is that each row of data
in the Worksheet consists of a separate database entry, and each column in the Worksheet represents
a single parameter stored within the chosen database.
Looking at Figure 2.22, the Worksheet contains a single row at the very top that has the “header”
information, or names of the individual parameters that collectively comprise a single database entry.
In this example, the header names are Product, Size, Sleeve, Inseam, Waist, and Color. Notice that, for
each product, not all of the parameters are populated. For example, shirts do not have inseam or waist
values, and pants do not have sleeve lengths. It is perfectly legitimate to leave a parameter null or
empty in a database. It is also perfectly legitimate to have a parameter that is the same for every database
entry. For example, if a particular shirt only came in the color blue, every color entry for that make of
shirt would be populated with blue. Why even include the parameter if it is always the same? Because,
if someone makes a query (or looks at the information contained within the database), they will want
to know the color of the shirt. Flat Files such as those shown in Figure 2.22 can be readily imported
into a database. To do so, such files are usually saved in a delimited format, with comma delimited
(*.csv) being the most common. Such files can be written into a network folder that is polled by the
database at regular intervals. When a file with a legitimate (or database readable) format is detected
within the network folder, the file can be automatically loaded into the database.
2.14
OBTAINING DRIVE, DIRECTORY, AND FILE INFORMATION
This entire chapter has been dedicated to the processes involved in reading and writing data. The
data that is to be read and written must, of course, come from somewhere. It is only fitting to
conclude with some routines that allow the programmer to correct errors that may occur when
