The L.A Fox Developer Newsletter

January 1997

Hot

Tip

Determining Data Changes

by Nelson M. Johnson, CCP

This month I was asked if there is any way to determine

whether data had changed in a FP 2.6 screen during an edit

session. It seems that this person had inherited an application

and wanted somthing they could easily fit into the existing

system. I suggested several methods, including using the

FIELDO function and a FOR...N EXT loop to test each field, but

by mutual agreement, we felt that was not acceptable. I offered

a utility I use in my applications that would do the trick but

would take a little more work because he would have to insert a

function call into all 58 Valid and When clauses. Now if you

really know me, I do have a shortcut because I am lazy and it is

really only a little more work.

The function is called zlChange.prg. What it does is save the

value of the field when you enter a it (the when clause) and then

compare it on the way out (the valid clause) to see if it changed.

You need to pass one parameter to tell it whether you are in a

when or valid clause. The parameter will be either a “w” or a "v"

respectively. Please take note of the lower case of the param-

eter. I design my system such that few, if any, screens are

directly called by a program other than their ‘handler’ program.

For example, USER.PRG would call USER.SPR. You should

use the de-snippetizing technique of removing all the code from

the screen and placing it into the .prg that called the screen;

You would group each fields’ when and valid together in a

procedure by the same name in that .prg. For example if you

have a field called Zip that has some validation, you would also

have a procedure in the .prg called ZipO. My reason for doing

this is that if you pass an upper case W or V to zlChange, that

indicates that there is a when or valid to execute in a proc with

the same name as the field.

ZiChange has one other benefit if the user presses the Escape

key, this will interrupt the regular field validation, and if there

have been changes to the screen, ask the users if they really

meant to quit. If yes, ziChange will simply return .t. to the field

so that the screen can go about closing without further valida-

tion. Note that there must be a "\?\<Cancel" button defined on

the form to make this work.

Download zlChange.prg

Now since I am the lazy kind of programmer, I thought it was

too much work to put my function into every When and Valid

clause by hand, so I made a program to open the screen

(which, if you didn’t know already) is really a table, and update

the When and Valid clauses for me. The heart of the program is

this:

replace

alt when with “zlChange(’w’)”, whentype with 0

for objtype = 15 and between(objcode,1,2);

and empty(when)

(Con’t, page 6)

Disk Fragmentation Under

Windows NT and Its Effect on

Database Performance

By Jim Slater, MVP

As Windows NT gains market share, it is increasingly likely

your applications’ data files will be located on a server or

workstation running NT. If so, you should pay close attention to

fragmentation on the NT volumes. As your data files grow

larger, they are very likety to become severely fragmented,

resulting in poor application performance. We all know who the

customer will blame when that happens.

Fragmentation describes a condition in which a single file on the

disk is not located in one contiguous area. Instead, it may be

broken into many small pieces scattered around the disk.

Large DBF and CDX files are particularly susceptible to this,

since they continually grow in size, but in small increments.

When Windows needs to allocate more space for the growing

file, there may not be any free space in the area immediately

past the end of the file. Instead, it will search forward until it

finds the next block of free space and use that to extend the

file.

While DOS and Windows know how to tie all the pieces to-

gether when accessing a fragmented file, it takes longer due to

the extra work required to locatc th3 pieces and to move tha

disk heads to the many disparate locations. The process of

retrieving and saving data in a DBF file usually requires multiple

disk reads from the DBF and CDX files, so they are particularly

sensitive to the level of fragmentation. Also, directories them-

selves (which are actually small system files on the disk) can

become fragmented, increasing the time it takes to locate and

open tables.

In addition to file fragmentation, your disk may suffer from “free

space fragmentation". When you delete a file from the disk, the

space freed up may be located between two existing files. This

leaves a small ‘hole’ of free space. Even if you have, say, 100

megabytes total free space on the volume, it may be broken

into hundreds of small ‘free space fragments’, none larger than a

couple of megabytes and many considerably smaller. If you

create a new file of several megabytes, it will be fragmented

from the beginning since it must be broken into pieces to fit into

the available free space fragments. Under certain conditions,

when data is being added to an existing file, NT does not look

around for a free space large enough to hold the new data, but

just begins using the next available free space even if it is too

small to hold all the new data.

Defragmentation programs rearrange the data on the disk so

that each file occupies one contiguous area. An option is

usually available to move all the files to the beginning of the

disk, consolidating the free space fragments into one large free

space area at the end of the disk.

(Con't, page 4)

Page 3