3
|
|
3 |
|
|
The L.A Fox Developer Newsletter
|
|
January
1997
|
Determining Data Changes
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 parameter. 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 validation. 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:
for objtype
=
15 and between(objcode,1,2);
and empty(when)
|
Windows NT and Its Effect on
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 themselves (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.
|
|
Page 3
|
|
|
3 |
|