CP/M

home *** CD-ROM | disk | FTP | other *** search

/ CP/M / CPM_CDROM.iso / lambda / soundpot / a / dbtips.lbr / DBREF.NZE / DBREF.NTE

Wrap

Text File | 1993-10-26 | 46.6 KB | 1,212 lines

INDEX TO dBASE II USAGE TIPS ============================ Menu Choice Item ---------------------------- 1 # function $ (substring) function with length of zero & (macro) function @...GET and function key input @...SAY...GET @...SAY...GET @...SAY...GET 2 Address to load assembly routines APPEND FROM ... DELIMITED APPEND FROM ... SDF with large records APPEND FROM <filename> FOR # > <number> APPENDing a text file with Tab characters CREATE -- Cannot CREATE or RENAME using reserved device names dGEN - Add Option dGEN - Limit 14 Fields dGEN - Report Option Disabling Page Ejects dSORT Patch for some 8-bit Computers 3 EDIT - Entering alternate characters in a datafile ESC key on CP/M-86 Expressions - Nesting limit of 7 parentheses FILE IS CURRENTLY OPEN error message FOR <numeric> clause 4 FOR and WHILE clauses, using both in same statement INDEX - Creating duplicate index entries INDEX - General rules Index operation INDEX, another way to TRIM the key expression INDEXing on a field in another SELECTed area 5 INSERT [BEFORE] [BLANK] on an indexed database file LIST FILES LOCATE LOCATE and CONTINUE MODIFY COMMAND command line limit MODIFY STRUCTURE, Restoring a database file after 6 Numeric precision at 10 digits PACK QUIT TO considerations REPLACE ALL on an indexed database file RESET SET ALTERNATE TO <file> SET COLOR on the TI Professional SET DELETED ON/OFF 7 SET FORMAT TO PRINT SET LINKAGE ON / OFF STORE - Cannot change TYPE of memvars TEST() function TOTALing on a numeric field ------------------------- { { {. 1 >>> # function. The # (current record number) function refers only to the data file in USE. When using the APPEND FROM command, if the # function is used in the FOR <exp>, the record number referenced will be the data file in USE and not the data file being appended. >>> $ (substring) function with length of zero. If you use the $(substring)function with a length parameter of zero, the $(substring) function will return a logical true (.T.) value rather than a null string. For example: STORE "abc" to string ? $( string,1,0 ) .T. his is true for all versions of dBASE II. >>> & (macro) function. The correct syntax when using two macros--one for the drive name and the other for the filename--is the following: USE &drive.:&filename ^-----------Notice where the period is placed. >>> @...GET and function key input. A function key string value may be entered into a memory variable with the use of the interactive commands, such as ACCEPT TO memvar and INPUT TO memvar. For example, with the following command sequence, SET F1 TO "ABC;" ACCEPT "Enter a value " TO memvar pressing F1 at the ACCEPT prompt will place "ABC" in the memory variable, memvar. However, function key string values cannot be entered in @...GET commands. The cursor will not respond to any function key input. >>> @...SAY...GET (1) The output of an @...SAY with a $ (substring) function in its <exp> will not display correctly when the third parameter in the $ function is a numeric variable. For example, the following code will display a "t" on the screen rather than "thi." STORE "this is a string" TO source STORE 3 TO length @ row,col SAY $( source, 1, length) The work-around is to STORE the substring to a memory variable and display the memory variable: STORE $( source, 3, 8 ) TO workstring @ row,col SAY workstring (2) When using an @...SAY...USING statement with an "xxxx" or an "AAAA" format to display a string variable, the "x"s or "A"s are displayed instead of the value in the variable. The work-around is to use uppercase "X"s instead of "x"s or "A"s. (3) After 64 @...GETs the cursor will jump to an unexpected location on the screen (usually, to the far right of the screen) and the system will hang. The work-around is to use CLEAR GETS or ERASEbeorethe64t GT to clear the GET table. (4) An @...GET with a PICTURE format beginning with a period will not work correctly. For example, STORE 0.000 TO number @ row,col GET number PICTURE ".999" READ In the above code, when one enters a value of 123, the number memvar will receive a value of 123.000 instead of the desired value of 0.123. The work-around is to begin the PICTURE clause with the character nine: STORE 0.000 TO number @ row,col GET number PICTURE "9.999" READ (5) The @...SAY will ignore the TRIM() function and print the argument of the TRIM() with its trailing blanks. The following example will print "hello " and not the desired "hello": STORE "hello " TO source @ row,col SAY TRIM( source ) The work-around is to STORE the argument of the TRIM() function to a memvar and display the memvar: STORE "hello " TO source STORE TRIM( source ) TO workstring @ row,col SAY workstring >>> @...SAY...GET (1) You should verify that the correct function symbols are used in the PICTURE and USING clauses because dBASE II will not trap incorrect symbols. (2) You may use the "#" and "9" functions in the PICTURE and USING clauses with numeric and character variables. However, @...SAY...USING will only display numeric type variables. @...GET...PICTURE will only allow entry of numbers whether the variable is defined as character or numeric. (3) You are properly using the "$" and "*" functions in @...SAY...USING with a numeric variable when replacing blanks. Do not use these functions in an @...GET...PICTURE. These functions should be used together with the "9" or "#" function, otherwise the number will be truncated from the decimal point to the end. For example, STORE 3.12 TO num @ 2,12 SAY num USING "$$$$" $$$3 @ 6,12 SAY num USING "$$9.99" $$3.12 (4) An @...GET with a PICTURE format beginning with a period will not work correctly. For example, in the following code: STORE 0.000 TO number @ row,col GET number PICTURE ".999" READ hen you enter a value of 123, number will receive a value of 123.000 instead of the desired value of 0.123. The work-around is to write the PICTURE clause with a leading nine, such as: STORE 0.000 TO number @ row,col GET number PICTURE "9.999" READ (5) You will use the "!" function properly when you use it in an @...GET...PICTURE command with a character type variable. Use this function only with character type strings. (6) Always verify that the PICTURE functions and lengths used in an @...GET...PICTURE clause correspond to the type and length of the variables used. If you use an incorrect PICTURE function in an @...GET with a numeric variable, the number will be incorrectly displayed and may alter the data in the variable. For example, on a PICTURE clause that is smaller than the field length, you will get the following (assuming Number is a numeric field of width 5 with 2 decimal places): REPLACE Number WITH 50.00 ? Number 50.00 * @ 17,5 GET Number PICTURE "9.99" :5. 0: ? Number 5.00 however, LIST will display the correct value of 50.00. Another example is if the PICTURE clause contains blanks in an @...GET...PICTURE, a READ command will drop through the variable being read. The blank character is not a valid PICTURE function. >>> @...SAY...GET (1) The USING clause is used with the SAY command and the PICTURE clause is used with the GET command. @...SAY...PICTURE, which is incorrect, will not result in a syntax error, but @...GET...USING, which is also incorrect, will state that there is an error in the field specification. (2) When you use a PICTURE or USING clause with lowercase "x"s (or any other invalid function) for a string variable, the "x"s are displayed instead of the value in the variable. This will also happen if the clause contains "A"s. The work-around is to use uppercase "X"s instead of: lowercase "x"s, "A"s, blanks, or other characters. 2 >>> Address to load assembly routines Assembly code subroutines should be loaded above EB00H (60160D) for 16-bit formats of version 2.41. The starting address for the 8-bit formats of this version is B000H (45056D). >>> APPEND FROM ... DELIMITED An attempt to use the WITH clause in the APPEND FROM DELIMITED command will give a syntax error. Instead, use the APPEND FROM <filename> DELIMITED command without the WITH clause. This defaults to comma delimited fields with double quotes around string fields. >>> APPEND FROM ... SDF with large records One cannot APPEND a text file with 998, 999, or 1000 characters per record into a corresponding dBASE II file. Any attempt to do this will append a blank record between each good record in the file. Records of 997 characters will correctly append into a similarly structured file. >>> APPEND FROM <filename> FOR # > <number> No records will be appended when using the following APPEND command: USE Dest APPEND FROM Source FOR # > 401 This is because the # (current record number function) only returns the record number for the current database file in use. The work-around is to use the following set of commands: USE Source COPY to Temp FOR # > 401 USE Dest APPEND FROM Temp >>> APPENDing a text file with Tab characters To append an ASCII file that contains Tab characters to a database file, do the following PIP command at the operating system level (for CP/M only): PIP A:ASCII.TXT=A:TABFILE.TXT[T8] This will replace each Tab character with eight blank spaces. You can put any number following the "T" in the statement. Consult your CP/M User's Guide for more information. Next, determine the proper structure to CREATE the database file by studying the ASCII.TXT file with DDT or by TYPE-ing the file in CP/M. Then, in dBASE II, use APPEND with the SDF option to append the text datafile into the CREATEd dBASE file. >>> CREATE -- Cannot CREATE or RENAME using reserved device names You cannot CREATE or RENAME a database file using one of the reserved device names found on page 6-13 of the IBM DOS 2.00 manual. Trying to CREATE a file with one of these names results in one of four conditions. I. Hangs the computer. LPT1 PRN II. Garbage to screen. CON <--- Recoverable, but no .DBF is created. III."END OF FILE FOUND UNEXPECTEDLY" LPT2 <--- The computer will hang. LPT3 NUL With printer online to computer PRN LPT1 IV."Read fault error reading device" [device name] "Abort, Retry, Ignore?" AUX COM1 COM2 <--- The computer will hang. >>> dGEN - Add Option Early copies of dGEN shipped with dBASE II version 2.43* generate code that will return the user to the main menu when an attempt is made to add a new record to the database file. This problem only occurs when the database file is indexed on a numeric field. The problem resides within the add module, option 2 in the main menu program. The code looks like this: DO WHILE addchoice <> 0 APPEND BLANK DO <file> CLEAR GETS READ * ---Code cannot be zero. STORE Code TO addchoice ENDDO The problem occurs because the command CLEAR GETS precedes the READ command in the program. When executing, the GETS defined in <file> are CLEARed before the READ command has a chance to enter the full-screen editing mode. To solve this problem, edit the file (xx-Main.PRG) so that the READ command precedes the CLEAR GETS command. >>> dGEN - Limit 14 Fields dGEN will generate screen designs for up to 14 fields. If you want a custom screen layout that contains more than 14 fields, the xx-Frame.PRG and xx-Gets.PRG. will have to be changed are to include more fields. Xx-Frame.PRG contains the field headings and xx-Gets.PRG contains the @...GETs. >>> dGEN - Report Option If you are using the report option of dGEN, and set the left margin to a value greater than 0, the resulting report run under the PC/MS-DOS version of 2.43*, will be spaced incorrectly when output to the printer. The reason is if the MARGIN is SET to a value greater than zero, printing multiple @...SAYs to the same line of the printer will include the margin setting between each @...SAY. For example: SET MARGIN TO 10 SET FORMAT TO PRINT @ 2, 5 SAY "This is a" @ 2,15 SAY "test" Will result in: This is a test ^---It should be printed here. To work around this problem, edit the report file and change SET MARGIN to 0. The SET MARGIN TO command line is one of the first SET commands near the top of the report file. If a left margin is desired, the values for the column positions of the @...SAY commands will have to be increased. >>> Disabling Page Ejects The following are the POKE sequences to disable page ejects in dBASE II version 2.43*. This allows duplicate reports to be printed on one page. As an example, assume a custom report is written using the @...SAY command with constants instead of memory variables for row and column coordinates. The command file may like this: SET FORMAT TO PRINT @ 2,20 SAY "Report Heading" @ 4, 2 SAY Field1 @ 5, 2 SAY Field2 @ 6, 2 SAY Field3 If the you try to print this report twice on one page, dBASE II will eject to a new page before printing the report a second time. There are two conditions that cause dBASE II to send a formfeed to the printer. One, when the EJECT command is used, and two, when the row coordinate of an @...SAY command being sent to the printer decreases in value. In the example above, after the first report is printed, the line counter is at line 7. Attempting to skip back to line 2 causes the formfeed. Refer to the May 1985 issue of TechNotes, page D2-3 for the POKE sequences for versions 2.3 through 2.41 of dBASE II and an explanation of how to control page ejects from within your programs alleviating the need for the POKE sequences. POKE sequence to disable the sending of the formfeed: POKE 16348,0,0 (version 2.43*, 8-bit) POKE 20974,144,144,144 (version 2.43*, PC/MS-DOS) POKE sequence to restore the sending of the formfeed: POKE 16348,205,5 (version 2.43*, 8-bit) POKE 20974,232,97,177 (version 2.43*, PC/MS-DOS) >>> dSORT Patch for Some 8-bit Computers There are two reported problems with dSORT running under CP/M 2.2. 1. dSORT gives a "d33 - UNDETERMINED ERROR OCCURRED" error message for computers that run ENABLED. 2. When a database file is sorted onto itself, garbage characters are inserted into the database file or added after the last record. The following is a patch that corrects these problems on some computers. It is not, however, always consistent from one version of a computer line to another. For example, the patch works as expected with recent versions of the Kaypro 2 and 4, but the second problem recurs with the older versions of the Kaypro 2. The patch also works fine on the double-density Osborne with the ROM 1.4, but on the Osborne with the ROM 1.43, dSORT gives the d33 error whenever a sort is attempted. To make the patch you will need to use the CP/M 2.2 debugging utility DDT following the instructions below. Be sure that you are patching a copy of dSORT and not the original. (1) Place a copy of DDT into the A: drive. (2) Place a copy of dSORT into the B: drive. (3) Type the following: A>DDT B:DSORT.COM <header information> NEXT PC XXYY 0100 -S0A3C 0A3C 22 C3 <Return> 0A3D C2 75 <Return> 0A3E 0A 12 <Return> 0A3F . <Return> -S1275 1275 00 22 <Return> 1276 00 C2 <Return> 1277 00 OA <Return> 1278 00 F3 <Return> 1279 00 C3 <Return> 127A 00 3F <Return> 127B 00 0A <Return> 127E . <Return> -S0ABD 0ABD 2A C3 <Return> 0ABE C8 7C <Return> 0ABF 0A 12 <Return> 0AC0 . <Return> -S127C 127C 00 2A <Return> 127D 00 C8 <Return> 127E 00 0A <Return> 127F 00 F9 <Return> 1280 00 FB <Return> 1281 00 C9 <Return> 1282 . <Return> -C A>SAVE 48 B:DSORT.COM you have now successfully patched dSORT. 3 >>> EDIT - Entering alternate characters in a datafile Alt <nnn> can be used in the EDIT and APPEND modes to enter extended characters into a database field. For example, holding down the Alt key and pressing "225" on the numeric keypad will enter the IBM extended character representation for the Greek character Beta. Additionally, you can use this method to insert extended characters into a command file that is initially created in MODIFY COMMAND. However, if you bring the command file into MODIFY COMMAND a second time, MODIFY COMMAND will strip the high order bit of the extended characters and leave you with characters on the lower half of the Extended ASCII Character Set. You can also use this method with output going to an Alternate file. >>> ESC key on CP/M-86 The Esc key must be pressed twice on CP/M-86 machines before it will take any effect. This is because CP/M-86 function key sequences all begin with Esc. When Esc is pressed once, dBASE II waits for the rest of the sequence before taking any action. (This is seldom noticed as users frequently hold down the Esc key when attempting to abort an operation.) >>> Expressions - Nesting limit of 7 parentheses There seems to be a limit of seven nested parentheses an expression can contain. An expression with eight parentheses followed by any LIST command will incorrectly bring up part of the error correction dialogue or reboot the computer. The following command sequence will illustrate this. STORE "ABCDEF " to mem1 STORE STR(((INT(((LEN(TRIM(mem1)))+1)/2))-1),1) to mem2 LIST STATUS >>> FILE() If the FILE() function is executed and the result is true (.T.), and then a different disk is inserted into drive B that does not contain the file last tested for, a second iteration of the FILE() will erroneously return a true (.T.) value. This occurs because the first time the FILE() function is executed, dBASE II checks the disk directory and loads an image of the directory into memory. For subsequent iterations of the FILE() function, dBASE II first scans the image and then the disk directory if the file being tested cannot be found in the image. If the command RESET B: is issued before the second execution of the FILE() function, the result will be false (.F.) because the RESET command forces dBASE II to access the disk when checking for the existence of a file. To ensure that dBASE II version 2.43* always checks the disk directory for the presence of a file, use the RESET command with a drive designator between successive executions of the FILE() function. If you are using a version of dBASE II earlier than 2.43*, you will find that the FILE() function accesses the disk to check the directory each time the FILE() function is issued. In this case, the RESET command is not necessary. >>> FILE IS CURRENTLY OPEN error message The error message, "FILE IS CURRENTLY OPEN," will result in the following three cases. CASE (1) You have structured your command files in such a way that a sub- program attempts to run the main program. For example, the main program might be: * Main.PRG ? "Inside main program" DO Sub1 *EOF: Main.PRG and the sub-program might be: * Sub1.PRG ? "Inside sub-program" DO Main <---- This is incorrect. * EOF: Sub1.PRG The "FILE IS CURRENTLY OPEN" error message will display as soon as dBASE II attempts to execute the "DO Main" command line in Sub1.PRG. Instead, use the RETURN command in sub-programs to get back to Main.PRG. CASE (2) You have written a command file that attempts to run itself. For example, * Main.PRG ? "Inside main program" DO Main<--- This is incorrect. * EOF: Main.PRG CASE (3) You are attempting to open the same database file in both the PRIMARY and SECONDARY work areas. SELECT PRIMARY USE Names SELECT SECONDARY USE Names<--- This is incorrect. >>> FOR <numeric> clause If you use a numeric expression as the sole argument of a FOR clause, all non-zero instances of the expression will be evaluated as true. For example: LIST FOR Number will list all records in which Number is not a zero. This will only work if Number is defined as a numeric field. However, LIST FOR .NOT. Number will not list records in which Number is equal to zero. This applies for all versions of dBASE II. 4 >>> FOR and WHILE clauses, using both in same statement A command that uses both FOR and WHILE in the same command line is improperly constructed, even though it will not return a syntax error. The last clause on the command line is the one that will be executed. >>> INDEX - Creating duplicate index entries The following command sequence will create duplicate key entries in an index file. If you do not intend to create duplicate entries in an index file, this is a programming practice you will want to avoid: USE Names INDEX Lname FIND Alpha STORE # TO recnum *---Close the index. SET INDEX TO *---Change the key field to "Beta" in the EDIT mode. EDIT recnum SET INDEX TO Lname FIND Alpha *---Change the key field to "Beta" in the EDIT mode. EDIT recnum *---Both key fields are now in the index. FIND Alpha FIND Beta >>> INDEX - General rules (1) The index expression or its contents cannot exceed 100 characters. (2) dBASE II permits indexing on the concatenation of numeric fields, but the numeric values will be added when generating the key. The fields will have to be converted to STRings when creating the index. For example, INDEX ON STR( part:no, 5 ) + STR( subpart, 3 ) TO Xparts >>> Index operation (1) Neither the index key expression nor its contents can exceed 100 characters. This is true even if macro substitution and substring functions are used in the INDEX ON command line. An example of computing the length of the key expression and the length of its contents is shown with the following INDEX ON command. INDEX ON Name + Address TO Myindex ^ ^ |____________|___ This is the key expression. (a) The length of the key expression is 14. The plus sign and spaces before and after the plus sign are included in the count. (b) Assuming Name is a character field of width 20 and Address is a character field of width 30, the length of the key contents is 50. (2) dBASE II allows you to create an index on a logical expression, but the records will not be indexed correctly. For example, the following INDEX ON command line is permitted, but you will find the index file to be useless. INDEX ON (Name = "Smith") TO Myindex (3) dBASE II allows you to create an index on the concatenation of numeric fields, but the numeric values will be added (not concatenated) in the expression evaluation. With the following INDEX ON command: INDEX ON Level + Quantity TO LQindex where, Level is a numeric field of width 3 Quantity is a numeric field of width 5 and RECORD 00001 contains the following: Level=3 Quantity=100 he index key value created for RECORD 00001 will have the value of 103 (that is, 3 + 100 = 103). Instead, concatenate the numeric STRing values when creating an index on numeric fields. Using the above example, this can be done in the following manner: INDEX ON STR( Level,3 ) + STR( Quantity,5 ) TO LQindex >>> INDEX, another way to TRIM the key expression dBASE II does not allow the use of the TRIM() function when creating an index. Quite often you will want an index on the concatenation of two character fields in which the first field is TRIMmed. Another way of accomplishing the same result is to use the minus operator, as in the example below. . USE Names . INDEX ON Fname-Lname TO Namex 00004 RECORDS INDEXED . LIST 00002 JOE SMITH 00003 OPHELIA UP 00004 SHECKY LING 00001 TOM RETTIG . FIND TOMRETTIG . DISPLAY 00001 TOM RETTIG The difference between using TRIM() and the minus ("-") operator is that TRIM() removes the blank spaces and the minus operator moves them to the end of the string. Using TRIM() in an INDEX expression would create variable length keys which dBASE cannot handle. >>> INDEXing on a field in another SELECTed area It is possible to INDEX on a field which is not in the currently selected work area when two database files are in use. It makes no sense to do this and the index file which is created will be useless, but dBASE II does not trap this as an error. In the following example, File1 contains Field1 and File2 contains Field2. SELECT PRIMARY USE File1 SELECT SECONDARY USE File2 * --- File2, which contains Field2, is the currently * --- selected file. INDEX ON Field1 to Ndxfile * --- This will return the message that all records have * --- been indexed. The index can be opened with SET * --- INDEX TO, but it has no value. No error message * --- appears when this last command is executed. dBASE II will also allow indexing on a memory variable if that variable is active. No error message will be given in this instance either. 5 >>> INSERT [BEFORE] [BLANK] on an indexed database file INSERT BLANK on an indexed database file will bring up full- screen edit. Also, INSERT and INSERT BEFORE will act as an APPEND when adding records; it will not insert into the indexed database file. These two items are already documented: INSERT BLANK in the dBASE II version 2.41 Change Summary and INSERT [BEFORE] in the Reference section of the manual. >>> LIST FILES If a file is not a dBASE II database file but happens to have a 02H as the first byte, a LIST FILES may list the file and give the error message, "NOT A DBASE II DATABASE." >>> LOCATE The LOCATE and CONTINUE commands cannot be used between two data files. If the PRIMARY file uses a LOCATE, then the SECONDARY uses a LOCATE, a CONTINUE back in the PRIMARY will result in a SKIP to the next record and not a CONTINUE. The following program segment illustrates how to LOCATE and CONTINUE between two data files. SELECT SECONDARY USE Location SELECT PRIMARY USE Names LOCATE FOR Name > " " DO WHILE .NOT. EOF ? "Customer Name: ", Name SELECT SECONDARY LOCATE FOR Code = P.Code DO WHILE .NOT. EOF ? " Location: ", Address SKIP LOCATE NEXT 65535 FOR Code = P.Code ENDDO SELECT PRIMARY SKIP LOCATE NEXT 65535 FOR Name > " " ENDDO >>> LOCATE and CONTINUE The LOCATE and CONTINUE commands cannot be used on two database files at the same time. If the PRIMARY file uses a LOCATE, then the SECONDARY uses a LOCATE, a CONTINUE back in the PRIMARY will result in a SKIP to the next record and not a CONTINUE on the LOCATE expression. The following program segment illustrates how to LOCATE and CONTINUE on two database files. * ---Open the files. SELECT PRIMARY USE Names SELECT SECONDARY USE Location SELECT PRIMARY * * ---Begin the LOCATE on the PRIMARY file. LOCATE FOR Name > " " DO WHILE .NOT. EOF ? "Customer Name: ", Name * * ---Begin the LOCATE on the SECONDARY file. SELECT SECONDARY LOCATE FOR Code = P.Code DO WHILE .NOT. EOF ? " Location: ", Address SKIP * * ---"CONTINUE" the LOCATE on the SECONDARY file. LOCATE NEXT 65535 FOR Code = P.Code ENDDO * * ---"CONTINUE" the LOCATE on the PRIMARY file. SELECT PRIMARY SKIP LOCATE NEXT 65535 FOR Name > " " ENDDO >>> MODIFY COMMAND command line limit dBASE II uses a 254 byte buffer to interpret a command line. If a command line reaches or exceeds the buffer limit (such as with a REPLACE command), dBASE II will give unpredictable results. No error message is given. >>> MODIFY STRUCTURE, Restoring a database file after If you have zeroed out the record count of a database file by using MODIFY STRUCTURE, you can restore it by using the FIXHEAD.BAS program found in the February 1985 issue of TechNotes. FIXHEAD.BAS will allow you to restore the record count and remove the end-of-file marker which MODIFY STRUCTURE places at the end of the header. 6 >>> Numeric precision at 10 digits When performing arithmetic functions with 10 digit numbers, the number with the fewer digits must appear first in the multiplication of the two numbers or the last digit of precision will be lost. For example, . ? 2 * 1234567891 2461935782 . ? 1234567891 * 2 2461935780 >>> PACK (1) PACK does not release the space made available when removing deleted records. The data file will take up the same disk space as before. This was done for applications which need to preallocate disk space and still be able to delete records. COPYing the data file to a new file is the only way to make the unused space available. The COPY command will not copy deleted records. The old data file can then be erased from the directory or saved as a backup data file. (2) Zeroing-out a data file containing a large number of records with DELETE ALL and PACK may be a time-consuming process. A faster way of zeroing-out a data file with many records is: USE Origfile COPY STRUCTURE TO Temp USE DELETE FILE Origfile RENAME Temp TO Origfile (3) Since the PACK command alters the database file in USE, backup procedures should be performed before attempting to PACK it. In the event a PACK procedure fails because of a power glitch or failure, then the backup data file can be reinstated and the PACK procedure restarted. (4) If a PACK procedure has failed due to a power glitch or failure, an end-of-file mark may have been inserted in the middle of the data file and the record count (contained in the file's header) may be incorrect. The records following the inserted EOF mark are consequently rendered inaccessible (by such commands as LIST, LOCATE, etc.). If no backup data file is available then you will need to: a) Change the record count to reflect the number of records actually contained by the file (see Technical Support Note # 16 for changing the record count). b) COPY the top and bottom portions (that is, COPY around the embedded end-of-file mark) of the file to two separate data files. (Use the NEXT option of COPY's <scope> clause to accomplish this.) Combine the two files using APPEND FROM. For example: USE Sickfile COPY TO Goodfile <---Copy to the embedded EOF. GOTO # + 2 <---To get around the embedded EOF. * ---The record containing the * ---embedded EOF will be lost. COPY NEXT 65535 TO Temp <---Copy last portion of file. USE Goodfile APPEND FROM Temp CLEAR DELETE FILE Sickfile DELETE FILE Temp >>> QUIT TO considerations QUIT TO only works under DOS 2.0 or later. Otherwise, it will create a file called Dbquitto.BAT and return to the dot prompt. Under DOS 2.0, Command.COM must be on the same disk directory as dBASE II. Otherwise, the error message, "NESTING LIMIT VIOLATION EXCEEDED," will be displayed when QUIT TO is executed and Command.COM is missing. >>> REPLACE ALL on an indexed database file REPLACE ALL does not replace all records correctly if an index is in use and the key field is REPLACEd. Only the first record and those that logically follow the new value will be REPLACEd. This occurs because the index is automatically updated (in-place key updating) when it is edited. Then the record pointer moves to the record following the new position, not to the record following the old position. This can be illustrated in the example given below. The data file has five records with the field CHARS-C-1, and is indexed on this field. The following sequence demonstrates what occurs. . LIST Record# CHARS 1 a 2 b 3 c 4 i 5 j . REPLACE ALL Chars WITH 'd' 00003 REPLACEMENT(S) . LIST Record# CHARS 2 b 3 c 1 d 4 d 5 d Page B114 of the manual, paragraph 3, warns against block replacements to the key field. The correct procedure would be to REPLACE with no indexes in use, open the indexes with SET INDEX TO, and then REINDEX. >>>REPORT FORM Reports generated by the REPORT FORM command in dBASE II version 2.43* now include records marked for deletion when SET DELETED is OFF and exclude deleted records when SET DELETED is ON. This differs from prior versions of dBASE II where the REPORT FORM excluded records marked for deletion regardless of the status of SET DELETED. Working around this situation for versions prior to 2.43* is possible, though not always convenient. To do so, all records printed must be active at the time that REPORT FORM is executed. First MODIFY the STRUCTURE of the database file to include a one- character status field. At the time the report is to be executed, use the REPLACE ALL command to replace the status field with an "N" for all records not marked for deletion. Then RECALL ALL so that all records marked for deletion are active and reportable. Finally, execute the REPORT FORM with a conditional FOR clause which excludes the records that do not have the value of "N" in the status field. The command syntax is: * ---Mark all the nondeleted records. REPLACE ALL <Status> WITH "N" RECALL ALL * * ---To report on all records. REPORT FORM <filename> * * ---To report on active records only. REPORT FORM <filename> FOR Status = "N" * * ---To report on records marked for deletion only. REPORT FORM <filename> FOR Status <> "N" Once you have finished REPORTing, issue the DELETE command to delete all the records which were marked for deletion before the REPORT FORM was run, and blank out the status field throughout the entire database file. The commands are: DELETE ALL FOR Status <> "N" REPLACE ALL Status WITH " " If the edit of the database file is done in a command file, use the REPLACE command within your program. For example, before a record is marked for deletion, REPLACE Status with "D" for that record. Please note that if your database file is large, following these suggestions can be time-consuming. >>> RESET When using CP/M at the operating system level, it is necessary to type Ctrl-C each time a new disk is inserted into a drive. This resets the CP/M bit map after a disk has been swapped and is referred to as a warm boot. If Ctrl-C is not executed between disk swaps, an I/O errors occur. In dBASE II, it is also necessary to reset the system between disk swaps. The equivalent to Ctrl-C is the RESET command so that each time a disk is swapped within a session of dBASE, the RESET command must be issued. The dBASE II documentation manual discusses the RESET command as it refers to the CP/M versions of dBASE II and not the PC/MS-DOS versions. Though PC/MS-DOS does not require the system to be RESET every time a new disk is inserted, some operations in version 2.43* require that the RESET command be used. For instance, if COPY TO is used to transfer data from one drive to another, from C: to A: for example, the data transfers correctly. However, if after the first COPY TO, the disk in drive A: is replaced with another disk and COPY TO is issued a second time using the same target filename, the second disk will be rendered unusable and may contain lost clusters. This problem only occurs if the same target filename is used for both disks. For example: USE C:Test COPY TO A:Temp <Disk 2 is inserted into drive A:> COPY TO A:Temp <drive> between the two COPY operations prevents this problem. When using the RESET command it is necessary to use a drive designator. It does not have to refer to a particular drive; any letter works. If RESET is not used with the drive designator, the file is not copied to the second disk, though dBASE still displays a message indicating that the copy was completed. RESET is also necessary when using the FILE() function. Please refer to the dBASE II Usage Tips section in the September 1985 issue of TechNotes for details concerning this function. >>> SET ALTERNATE TO <file> When used with a filename, the SET ALTERNATE TO command will assign all text (control characters are not allowed) output to a disk file. The SET ALTERNATE TO without a filename will close the ALTERNATE file. This command is used in conjunction with the SET ALTERNATE ON/OFF flag. The SET ALTERNATE ON will begin the alternate writing process, and the SET ALTERNATE OFF will turn it off. @...SAY commands do not send output to the ALTERNATE file (that is, not with the SET ALTERNATE ON command alone). You will have to use the SET FORMAT TO PRINT command in addition to the SET ALTERNATE ON, as follows: SET ALTERNATE TO <filename> SET ALTERNATE ON SET FORMAT TO PRINT * ---Disable the printer (limited to CP/M 2.2). POKE PEEK( 2 ) * 256 + 15, 201 * * Statements using the @...SAY commands go here. * * ---Enable the printer (limited to CP/M 2.2). POKE PEEK( 2 ) * 256 + 15, 195 SET FORMAT TO SCREEN SET ALTERNATE OFF SET ALTERNATE TO >>> SET COLOR on the TI Professional >> Monochrome monitor: The SET COLOR TO <x>,<y> command can be used to change the screen attributes of the SAY and GET statements. The first number <x> changes the SAY , and the second number <y> changes the GET. The GET will only be changed with SET INTENSITY ON. READ and ERASE will reset the video attributes to normal video. The following numbers produce these results forboth <x> and <y>. There is a range of seven intensity levels for each video attribute. 0 Blanks 9 Lowest intensity 15 Highest intensity 25 Lowest intensity reverse video 31 Highest intensity reverse video 41 Lowest intensity underlined 47 Highest intensity underlined 73 Lowest intensity flashing 79 Highest intensity flashing 89 Lowest intensity flashing reverse video 95 Highest intensity flashing reverse video 105 Lowest intensity flashing underlined 111 Highest intensity flashing underlined When dBASE II is loaded, the color setting is SET COLOR TO 12,15 (where 12 is an intensity shade between 9, Lowest intensity, and 15, Highest intensity). >> Color Monitor: With a color monitor the <x> and <y> attributes are the same. The only difference is that colors will be produced without the range of video intensities. The following chart gives you the numeric values to use. COLOR NORMAL REVERSE UNDER FLASHING FLASHING FLASHING VIDEO LINED REVERSE UNDERLINED ----------------------------------------------------------------- Blue 9 25 41 73 89 105 Red 10 26 42 74 90 106 Violet 11 27 43 75 91 107 Green 12 28 44 76 92 108 Light blue 13 29 45 77 93 109 Yellow 14 30 46 78 94 110 White 15 31 47 79 95 111 >>> SET DELETED ON / OFF (1) On page B-136 of the dBASE 2.4 and 2.41 manual in the paragraph beginning with "19. DELETED," states that, "records marked for deletion cannot be located with the FIND command nor processed by any command that allows the NEXT phrase (e.g. LIST, LOCATE, COUNT, etc.)" if SET DELETED is ON. This also applies to SKIP, though the syntax for this command does not support a NEXT phrase. (2) You cannot COPY, APPEND, REPLACE into, or REPORT deleted records whether SET DELETED is ON or OFF. (3) If SET DELETED is ON and the pointer is positioned to a record just before a deleted record, SKIP, SKIP+1, and SKIP+2 each point to the next undeleted record immediately after the deleted record. You might assume that SKIP and SKIP+2 will point to two different records, but they point to the same one. (4) SET DELETED ON only works with the currently selected work area. For example, if SET LINKAGE and SET DELETED are both ON and a LIST command is executed on the PRIMARY file, records marked for deletion in the SECONDARY file will be listed (until the PRIMARY file reaches the end-of-file marker). 7 >>> SET FORMAT TO PRINT If you are using @...SAYs to output to the printer with SET FORMAT TO PRINT and you press the Esc key, the SET FORMAT TO SCREEN command will not get you back to the screen. The dot prompt will appear on the printer and commands can be entered and will execute, but these will be echoed to the printer only. Type SET CONSOLE ON and SET PRINT OFF to allow commands to echo back to the screen. >>> SET LINKAGE ON / OFF SET LINKAGE ON links the file pointers of both PRIMARY and SECONDARY data files. Positioning will be performed on all sequential commands that have a <scope> parameter (such commands as LIST, REPORT, and LOCATE). Some known restrictions to the use of this flag are listed below. The most common error message reported on this command is the "BDOS ERROR ON [: SELECT". The restrictions are: (1) Both PRIMARY and SECONDARY data files must be indexed or not indexed (that is, both must have an index open or not opened). (2) Both must have the same number of records. The number of fields does not make a difference. >>> STORE - Cannot change TYPE of memvars You cannot change the TYPE of a memory variable and retain the memory variable's original value. For example, the following command sequence will leave num with the value of the character string " 0" and not " 1234": . STORE 1234 TO num . STORE STR( num, 5 ) TO num . ? num, LEN( num ) 0 5 >>> TEST() function The TEST() function is used to test the parseability of a dBASE II expression. The important words to remember are "parseability" and "expression". The TEST() function will only test to see if the dBASE II interpreter can successfully parse an expression (that is, is it syntactically correct) and will not test to see whether or not the expression is valid. For example, if A=1 and B=2, and both variables are predefined, then ? TEST(A=B) will be evaluated as parseable. The TEST() function will only test an expression. The portion of a command that follows the "FOR" is the expression. Consult your dBASE II manual for a further definition of an expression. The TEST() function will return different numeric values depending on the expression it has parsed: TEST() result is: The expression is: The expression type is: ----------------- ------------------ ----------------------- 0 non-parseable N/A -6 parseable Numeric positive number parseable Character or Logical A short program example of how the TEST() function can be used is given below: USE Names DO WHILE T ACCEPT ". LIST FOR " TO express IF express = " " RETURN ENDIF IF 0 = TEST(&express) ? "*** BAD EXPRESSION ***" ELSE LIST FOR &express ENDIF ENDDO >>> TOTALing on a numeric field If you TOTAL on a numeric field, it is necessary to use a FIELDS phrase that does not include that field name. The reason for this is that dBASE uses the target record and compares its contents to the next record in the database file as it is totaling. If you are trying to total the field that you are TOTALing ON, the contents in the target record for that field changes with each record. Therefore, if the first three records in the file have the same key value, the third record in the file will not match the target record because it is the sum of the first two and TOTAL will not group them together. A detailed example follows. The file structure of Test.DBF is: Name-C-10, Num1-N-5, Num2-N-5. Assuming it is INDEXed on Num1, a LIST would display the following: NAME NUM1 NUM2 Adam 1000 200 Sue 1000 300 Mary 1000 200 Tom 2000 100 Bob 2000 200 Ted 4000 100 Alice 4000 200 So you enter TOTAL ON Num1 TO Test2 and... WHAT YOU EXPECT IS: BUT WHAT YOU GET IS: Adam 3000 700 Adam 2000 500 Tom 4000 300 Mary 1000 200 Ted 8000 300 Tom 8000 400 Alice 4000 200 What follows is a table of what is going on internally: RECORD CURRENT RECORD TARGET RECORD ACTION TAKEN 1 Adam 1000 200 none write & skip 2 Sue 1000 300 Adam 1000 200 add & skip 3 Mary 1000 200 Adam 2000 500 write & skip 4 Tom 2000 100 Mary 1000 200 write & skip 5 Bob 2000 200 Tom 2000 100 add & skip 6 Ted 4000 100 Tom 4000 300 add & skip 7 Alice 4000 200 Tom 8000 400 write & skip EOF none Alice 4000 200 stop