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 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 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.