home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Shareware Overload
/
ShartewareOverload.cdr
/
database
/
db3tips2.zip
/
DB3MISC.TXT
< prev
next >
Wrap
Text File
|
1986-07-01
|
8KB
|
205 lines
dBASE Speed Tips
(PC Magazine Vol 5 No 1 January 14,1986 Power User)
These tips help shave off every possible microsecond from you
dBASE command files. While some of the more general suggestions may
contradict everything you've ever learned about writing dBASE programs,
they cut the execution time for your programs to the bare minimum.
Code-optimizing measures like these should not be used if program
readibility is important. Your applications should be thoroughly
debugged and tested before you implement the following procedures.
With complicated programs, however, the cumulative effect these steps
can have on the speed of operation is impressive.
1. Left justify everything: No indentations for IFs, DO CASESs
or DO WHILEs.
2. All field, variable and filenames should use as few letters
as possible.
3. Locate those field used in indexing, sorts or LOCATES at the
top of your data files' structures.
4. Eliminate all comment lines (any line beginning with *).
5. Use commands such as SET TALK OFF and SET CONSOLE OFF when
you don't need messages, preventing unnecessary use of the processor.
6. Trim line lengths by eliminating spaces wherever dBASE allows,
e.g., turn DO WHILE K = 5 .AND. I = "MOM" into DO WHILE K=5.AND.I=
"MOM".
7. Delete redundant statements such as a GO TOP after a USE
<filename> command, a CLEAR GETS after ERASE, or LOOP as the last line
of a DO WHILE routine.
8. Use capital letters as much as possible. Lowercase letters
take a little longer to identify.
9. Take advantage of the fact that dBASE only reads the first
four letters of a command. Never use APPEND where APPE will suffice.
-----------------------------------------------------------------
A Pseudocompiler for dBASE II
(PC Magazine Vol 5 No 5 Mar 11, 1986 Power User)
Too often, dBASE II command file writers are disappointed with
the speed at which their lengthy programs run, especially with large
data files. Many times, this degradation in speed occurs because of
the way in which the application was programmed, not because of an
increase in the number of records in the files.
One good way to improve the speed at which a program executes is
to limit the number of STORE and REPLACE commands used. dBASE must
access your disk every time it encounters one of these commands.
Therefore, changing your code from:
STORE ' ' TO m:one
STORE ' ' TO m:two
STORE " " TO m:three
REPLACE one WITH m:one
REPLACE two WITH m:two
REPLACE three WITH m:three
to read:
STORE ' ' TO m:one,m:two,m:three
REPLACE one WITH m:one,two WITH m:two,three WITH m:three
instead, will dramatically limit the number of disk accesses, speeding
things up considerably.
Because of dBASE's interpretive nature, such things as blank
lines, comments (lines starting with *), and the indenting of program
lines also slow a command file's execution times. However, eliminating
all these items from your program may be more trouble than it's worth
if you must later rewrite or debug your program.
The "pseudocompiler" below, while not even close to a true
compiler, will take your program and strip all blank and comment lines
from it while left-justifying all code. It produces a second version
of your code with a C on the end of the original name, which you can
use in place or your original. Your original program is left intact
for documentation, debugging, and other purposes.
Editor's Note: This routine automatically adjusts your existing
command files to take advantage of many of these tricks while leaving
your original programs untouched. COMPILE.PRG is shown with indenta-
tions, comment lines, etc. but you might want to run its code through
itself to make it run faster. Be sure you have a data file called
COMPILE.DBF (consisting of one character field 254 bytes in length)
on your disk before running COMPILE.PRG.
One word of caution: COMPILE.PRG strips away semicolons at the
end of each line of code that is continued on the next line. Therefore,
you should go through the "compiled" version of your code and replace
the missing semicolon on any partial lines remaining in the program.
* COMPILE.PRG
* Requires COMPILE.DBF file that has one field called LINE which is
* defined as character and is 254 characters in length.
CLEAR
SET COLON OFF
SET TALK OFF
SET ECHO OFF
SET BELL OFF
USE COMPILE
COPY STRU TO TEMP
USE TEMP
ERASE
STORE ' ' TO PROGNAME
@ 10,20 SAY 'ENTER THE NAME OF THE PROGRAM TO BE COMPILED'
@ 11,30 GET PROGNAME PICTURE '!!!!!!!!'
@ 11,38 SAY '.PRG'
READ
STORE TRIM($(PROGNAME,1,7))+'C.PRG' TO M:PROG
STORE TRIM(PROGNAME)+'.PRG' TO PROGNAME
APPEND FROM &PROGNAME SDF
GO TOP
SET ALTERNATE TO &M:PROG
SET ALTERNATE ON
DO WHILE .NOT. EOF
STORE 1 TO CNT
DO WHILE ($(LINE,CHT,1)=' ' .AND. CNT<50) .OR. $(LINE,CNT,1) = CHR(9)
STORE CNT+1 TO CNT
ENDDO
IF $(LINE,CNT,1) = '*' .OR. $(LINE,CNT,1) = ' '
DELETE
ELSE
STORE TRIM($(LINE,CNT,254-CNT)) TO M:LINE
? M:LINE
ENDIF
SKIP
ENDDO
SET ALTERNATE OFF
USE
DELETE FILE TEMP
QUIT
-----------------------------------------------------------------
More on dBASE III Function Keys
(PC World February 1986 Star-Dot-Star)
Another tip on setting dBASE III function keys ... This technique
does not require changing the key definitions. When the WAIT TO
statement is active, the function keys will return ASCII values 246
through 255. The program DKEYDEMO.PRG below demonstrates how those
key codes can be handled by a dBASE III application. The demonstration
merely displays the name of the function key you press. An actual
application would most likely execute a DO statement instead.
A second unrelated technique involves eliminating the CASE
statement entirely; instead, use the SET FUNCTION statement to define
each key with "DO program-name;" (the semicolon will appear as the
<Enter> key when the statement executes). Your menu progran can ACCEPT
the user's response to a variable, then execute that variable using the
dBASE III &variablename macro feature.
DKEYDEMO.PRG:
* This menu uses function keys without chaning their definitions.
* When the WAIT TO statement is active the function keys return
* ASCII values from 246 to 255. Since 255 is a null character it
* must be handled differently than the others, as shown by the
* last item in the CASE statement below.
DO WHILE 1=1
CLEAR
* (Use @SAY statements to display a menu more quickly)
TEXT
***** SAMPLE MENU *****
[F1] Whatever
[F2] etc.
ENDTEXT
WAIT ' Press a Function Key: ' TO action
DO CASE
CASE ASC(action) = 254
? "F2"
CASE ASC(action) = 253
? "F3"
CASE ASC(action) = 252
? "F4"
CASE ASC(action) = 251
? "F5"
CASE ASC(action) = 250
? "F6"
CASE ASC(action) = 249
? "F7"
CASE ASC(action) = 248
? "F8"
CASE ASC(action) = 247
? "F9"
CASE ASC(action) = 246
? "F10"
CASE action = ''
? "F1"
ENDCASE
WAIT
ENDDO
-----------------------------------------------------------------
dBASE Defect
(PC World April 1986 Star-Dot-Star)
dBASE III v1.1 has a problem that could result in the loss of
significant amounts of data. When the SET CARRY ON condition is in
effect and records are APPENDed to the end of a file, the image of the
last record is copied into the appended record. If, however, the last
record has its delete flag set on, the delete flag on the appended
records will be set on as well. When the data base is PACKed, all the
new records will be removed from the file because they are flagged for
deletion. The problem also exists when you use the INSERT command but
does not occur when you issue the APPEND FROM filename command.
Ashton-Tate advises that you use the SET CARRY ON and APPEND
commands with caution to avert potential data loss. One solution is
to always issue the SET DELETE OFF command prior to writing new
records to disk.