CP/M

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

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

Wrap

Text File | 1993-10-26 | 33.1 KB | 941 lines

dBASE II: A N O M A L I E S I N D E X ======================================= Menu Choice Item -------------------------------------- 1 Instructions 2 @...GET and numeric overflow @...GET...PICTURE with 9 or # @...SAY and relative addressing @...SAY past 128 lines @...SAY with the substring ($) function @...SAY with uninitialized variable Sending @...SAYs to the Printer APPEND SDF large records APPEND with large numeric fields 3 CHANGE and the Esc key COPY STRUCTURE DELETE ALL / PACK and ghost field values DISPLAY RECORD <number> with INDEX DO WHILE at byte 257 DO WHILE using Boolean expressions EDIT after a NO FIND 4 EOF File Structure corruption FILE() function Ignored commands after OTHERWISE and ELSE INDEX INDEX balancing INDEX ON 5 INDEXing with $ (substring) function INSERT BLANK JOIN JOIN, repeated use of Memory variable corruption Memory variables with long names Memory variables, Changing data types of 6 MODIFY STRUCTURE and header corruption MODIFY STRUCTURE procedures Parentheses Limitations QUIT TO on Wang PC QUIT TO with an ALTERNATE file open READ resetting the EOF flag REINDEX on a database file with no index REPLACE ALL 7 REPLACE and deleted records REPORT FORM and SET DELETED ON or OFF REPORT FORM with SET MARGIN TO REPORT FORM, numeric overflow on large reports SET FORMAT TO <filename> and EDIT SET MARGIN TO Sidekick and dBASE II incompatibility 8 SKIP with SET DELETED ON SORT changing the record count SUM with no records TEXT...ENDTEXT TOTAL command with FOR expression VAL() changes the type of a large numeric string 1 The Anomalies section describes the known anomalies (nd possible work-arounds) reported to the Software Support Center during the previous month. This information is gathered from customers who call or write to the Software Support Center, it is then tested by our technicians, and, finally, compiled in alphabetical order. If you discover what you believe is an anomaly (as defined below) not presented in this report, please send us a detailed description of the possible anomaly so we can try to reproduce it. If the reported anomaly can be reproduced by our technicians, it will be added to the next month's report. We use the word "anomaly" to mean any one of the following: o INCORRECT COMMAND (or function) IMPLEMENTATION. A command or function does not execute as specified. An example of this would be, if the INSERT command inserts a record after the current record pointer, but fails to move the end-of-file marker when the file is rewritten. o INCOMPLETE COMMAND (or function) IMPLEMENTATION. A command or function does not execute as specified in every use of the command or function. An example of this would be, if the semicolon character does not function as a continuation symbol for the DO WHILE command, but it does operate properly when executing any other command. o DATA OR LOGICAL BOUNDARY LIMITATION. A command or function cannot perform an operation at a specified data or logical boundary. For example, if the APPEND FROM <textfile> SDF does not append text lines with 998, 999, or 1000 characters per line. However, appending text lines with less than 998 characters will work. Another example would be, if repeated use of the JOIN command causes it to fail. The Software Support Center reserves the right to withhold further information pertaining to this section that may reveal proprietary or trade secret details. 2 >>> @...GET and numeric overflow When using @...GET <fieldname> with a numeric field for data entry and numeric overflow occurs, the field blanks out and does not display asterisks as it does on version 2.4. Upon redisplaying the @...GET <fieldname>, however, the asterisks will appear with a few numbers. Also, a LIST or DISPLAY of the fieldname will display zeroes and not asterisks. If DISPLAY STRUCTURE is entered prior to using @...GET, the @...GET will behave as it does on version 2.4. Two problems may occur with numeric overflow on input to a numeric field in an @...GET <fieldname> command: 1. The field will blank out instead of displaying asterisks. 2. Pressing Return on subsequent numeric fields in the same record will zero them out if they hold a value greater than zero. This can be illustrated in the command sequence below. All the fields are numeric with a length of 5 and a decimal width of 2. A numeric overflow can be created by entering a number such as 55555 (no decimals). ERASE @ 12,10 GET numfld1 @ 13,10 GET numfld2 @ 14,10 GET numfld3 @ 15,10 GET numfld4 READ CLEAR GETS LIST Enter DISPLAY STRUCTURE prior to using the @...GET command and the above problems will not occur. >>> @...GET...PICTURE with 9 or # If an @...GET memvar PICTURE statement is used to get a character string of numbers with embedded periods and the PICTURE clause uses 9's or #'s, the periods are changed to spaces. For example: STORE "11.22.33.44" TO mtest @ 5,0 GET mtest PICTURE "99999999999" READ ? mtest The GET statement will display "11 22 33 44". After a <RETURN> at the READ statement, "? mtest" will also display the numbers without the periods. >>> @...SAY and relative addressing The relative addressing feature that is used in conjunction with the @...SAY command does not keep track of the current screen position. It simply remembers the coordinates immediately to the right of the last @...SAY and substitutes those coordinates for the "$" symbol. That is, you do not get true relative screen addressing as can be seen in the following example: ERASE @ 1,0 SAY "line1" * The screen coordinates are (1,5). ? "line2" * The screen coordinates are (2,5). ? "line3" * The screen coordinates are (3,5). ? "line4" * The screen coordinates are (4,5), but the $ will be * replaced by 1, the row coordinate of the last @ * command. @ $,6 SAY "line5" >>> @...SAY past 128 lines When using @ row,col SAY, and row is a memory variable that is incremented past 128, formatting is thrown off. Displays and printing no longer appear where they should. This can be tested with the following program segment: SET FORMAT TO PRINT STORE 1 TO row DO WHILE row < 150 @ row, 1 SAY "ROW NUMBER " + STR( row, 3 ) STORE row + 1 TO row ENDDO >>> @...SAY with the substring ($) function Using the @...SAY command with the substring ($) function will not work properly if a numeric memory variable is used as the length argument to the function. Specifically, only the first character of the string will be displayed For example, the following set of commands will only display one "X" instead of five: STORE 5 TO length @ 10,0 SAY $("XXXXXXXXXX",1,length) There are several ways to work around this problem. One is to use macro substitution. For example: STORE "5" TO length @ 10,0 SAY $("XXXXXXXXXX",1,&length) A second is to STORE the result of the substring function to a memory variable, and SAY the memory variable. For example: STORE 5 TO length STORE $("XXXXXXXXXX",1,length) TO character @ 10,0 SAY character >>> @...SAY with uninitialized variable Attempting to @...SAY an uninitialized memory variable whose name begins with any of the letters T, F, Y, or N, will display a logical value at the specified coordinates rather than the error message "VARIABLE NOT FOUND." The logical value displayed will be T if the variable name begins with T or Y, and F if it begins with F or N. For example: @ 10,0 SAY F is equivalent to @ 10,0 SAY fixit if 'fixit' does not exist as a field name or memory variable. >>> Sending @...SAYs to the Printer On the Osborne format of 2.43*, when sending @...SAYs to the printer, dBASE II will insert two blank spaces between each @...SAY printing to the same line. However, this does not occur when the @...SAYs are output to the screen. For example: SET FORMAT TO PRINT @ 3,1 SAY "Hello" @ 3,7 SAY "there" Hello there ^----the second word should print here. >>> APPEND SDF 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 like structured file. >>> APPEND with large numeric fields In version 2.41, a numeric database field can be created with a length of up to 254 positions. However, APPENDing or EDITing a numeric field of 60 or more digits in length may cause several errors. When data is entered into this field, (1) the file structure may be overwritten with records from the database file, (2) the screen may fill up with garbage characters, (3) control may drop back to the operating system, or (4) the system may hang, requiring a warm boot or reset. The largest number dBASE II can handle is one to the 63rd power. This means you may have a number as large as a one with 63 zeros after it. If all these were digits other than zero, only the first 10 digits would show the actual value. The rest of the trailing digits would default to zero. While dBASE II will allow you to create a numeric field that is apparently larger than the limitations given above, the field will not be usable. 3 >>> CHANGE and the Esc key The Esc key is used to abort the CHANGE command, but if pressed in response to a numeric field, it will change the field to zero. >>> COPY STRUCTURE COPY STRUCTURE will not properly copy the record length, bytes 6 and 7, of the header record to the new database file. This anomaly will go unnoticed by most users, but if you happen to be reading the resultant file structure with another program, you will find that the header record contains a 20H in each of these positions. To restore the correct record length after a COPY STRUCTURE, PACK the file. >>> DELETE ALL / PACK and ghost field values If a database file is purged with a DELETE ALL and PACK, any query on the field names will give the field values for what used to be the last record in the file. The only way to avoid these "ghost" field values is to ascertain that there are records in the file before querying the field names. For example: USE <filename> IF .NOT. EOF ? Field1, Field2 ELSE ? "There are no records in this file." ENDIF Note that the EOF function always returns a logical true (.T.) for an empty database file. >>> DISPLAY RECORD <number> with INDEX The command DISPLAY RECORD <number> does not function properly with an index engaged. The following sequence: USE Filename INDEX Indexname DISPLAY RECORD 10 will display the number 00010 and position the file pointer at record 10, but will not display the contents of record 10. >>> DO WHILE at byte 257 If a command file has exactly 256 bytes, or multiple of 256 bytes, preceeding a DO WHILE statement, the DO WHILE will not execute and the program will drop back to the dot prompt or one level of program nesting higher. In other words, if the "D" in DO is at byte 257, 513, 769, 1025 etc., the file will not execute properly. Adding or subtracting one character before the DO WHILE solves the problem. >>> DO WHILE using Boolean expressions In a DO WHILE statement, contiguous Boolean operators will execute with inconsistent results when a "." is missing. The following two cases illustrate this. CASE 1: The following command line will not produce a syntax error and, when executed, will return a Boolean false (.F.) even when the condition is true. DO WHILE flag = "Y" .AND.NOT. EOF ^____missing period CASE 2: The following command line has an inserted space and executes correctly. The problem remains, however, that dCONVERT (the dBASE III conversion utility) will not convert this line correctly. It leaves out the test for end-of-file. DO WHILE flag = "Y" .AND .NOT. EOF ^____missing period >>> EDIT after a NO FIND The command EDIT # will not bring up a record to edit if it is preceeded by a FIND command that did not find a match ("NO FIND"). An error message will not be displayed. 4 >>> EOF If EOF is logically true (.T.) and a READ is subsequently executed on a memory variable, the EOF condition becomes logically false (.F.). >>> File Structure corruption On both the 8-bit and 16-bit versions of dBASE II the database file structure will be corrupted in the case where a command line uses a FOR clause with several Boolean operators containing a large character field (100 to 200 characters long). For example, the following command line will corrupt the database file header in memory when it is executed (assuming Fldnam is a character field of width 200): LIST FOR "A"$Fldnam .OR. "B"$Fldnam .OR. "C"$Fldnam .OR.; "D"$Fldnam .OR. "E"$Fldnam The explanation for this occurrence is as follows. As dBASE II interprets the FOR expression, it generates an intermediate string which cannot be longer than 1000 bytes. If the intermediate string exceeds the 1000 byte limit, it will begin to overwrite the next area in memory; this is the area where the file structure is located. The above command line substitutes 200 bytes each time Fldnam is referenced, plus the number of characters in the command line itself minus 30 bytes for the words "Fldnam" which are substituted. During the interpretive process the above command line will expand to 1053 bytes thus exceeding the 1000 byte buffer limitation and overflow into the adjacent area. The file on disk is unaffected unless the file is closed. >>> FILE() function The FILE() function will only check once for a file if a true (.T.) is returned. Any further checks will always return a true even if a disk is changed and that file is no longer available to dBASE II. >>> Ignored commands after OTHERWISE and ELSE Certain commands when typed from the dot prompt will cause dBASE II to ignore all commands that follow. Typing OTHERWISE or ELSE without a preceeding DO CASE or IF will place the interpreter in a hold pattern until a release command such as ENDCASE or ENDIF is typed. If TEXT is entered, you will not get the dot back until you type ENDTEXT. >>> INDEX In version 2.41 of dBASE II, there is a problem with the index file being rearranged when the key field is not changed. The problem will only occur on indexed database files with duplicate keys. The following example illustrates this. Suppose Customer.dbf has records 3, 4, 17, 22, and 59 that have a Name field containing "Smith". When the index file Custname.ndx is originally created, records with duplicate keys will be in record number order. A listing of names equal to "Smith" will give: 3 Smith 4 Smith 17 Smith 22 Smith 59 Smith The following command file will reorder the records in Custname.ndx to 4, 17, 22, 59, and 3. In other words, the first record is moved to the end of its duplicate key group. USE Customer INDEX Custname STORE "Y" TO answer FIND "Smith" DO WHILE Name = "Smith" .AND. answer = "Y" DISPLAY @ 10,0 "More records? [Y/N] " GET answer PICTURE "!" READ SKIP ENDDO No matter how the user responds, this command file will only process one record, because as soon as the READ is issued, record 3 gets moved to the end of its duplicate key group and the SKIP causes the condition Name = "Smith" to be false. If the command file is executed a second time, record 4 will be found; on the third run record 17 will be found; etc. In this example the problem can be remedied by adding the NOUPDATE phrase to the READ command. The user, however, will not be able to successfully use the EDIT command on an indexed file with duplicate keys. >>> INDEX balancing The balancing algorithm for index (B-tree) files will occasionally lose references to nodes in the index file. This anomaly clearly manifests itself when doing numerous edits to the key field(s). It also manifests itself in APPEND BLANKs and REPLACEs to the key field(s). The following steps give an example of how this can occur: (1) CREATE a data file with a character field of 40 characters and 100 records. (2) REPLACE a constant value to the character field for the records in the entire file. The syntax is: REPLACE ALL Char:field WITH <"Char string"> (3) INDEX ON the character field. (4) Now, set-up a program loop to FIND the first occurrence of the <"Char string"> and REPLACE a character string of random values to the key field. RESULT: After 30 FINDs and REPLACEs to the first 30 records in the data file, the index will FIND (jump to) the 36th record in the data file. It was determined that dBASE II had lost a reference to the node containing records 31-35. In some rotations of keys and pointers, dBASE II is incorrectly updating the node pointers. In particular, nodes on the right side of index subtrees are not being referenced. The two error messages that may indicate a lost node in the index file are: RECORD NOT IN INDEX. This is because the node containing the key expression and record number is no longer referenced. END OF FILE FOUND UNEXPECTEDLY. This is the most common error message that will result with this condition. It might (we don't know for sure) result from dBASE II following a node reference (of a misplaced node) that points to a position beyond the end-of-file for the index. Or, in the process of traversing the tree, dBASE II is losing its place along the way (because of missing nodes) and might eventually run into the end-of-file marker. The only work-around at this time, is to recreate the index. However, if the user never EDITs the key field, or never APPENDs BLANK and REPLACEs (rather, he/she either APPENDs FROM <filename> or simply APPENDs in full-screen mode), the problem will never manifest itself. An example of how to use an APPEND FROM technique is given below. Remember, this only applies o those applications that require the key fields to be modified. A batch method of updating records where the key field is expected to be modified is given below. The database file will have to be periodically PACKed when using this method. * ---Update.prg USE Mainfile INDEX Mainname COPY STRUCTURE TO Main.$$$ SELECT SECONDARY USE Main.$$$ STORE T TO is:more DO WHILE is:more SELECT PRIMARY ACCEPT "Enter name" TO mname IF mname = " " STORE F TO is:more LOOP ENDIF FIND &mname IF # = 0 ? "NO FIND" LOOP ENDIF DELETE SELECT SECONDARY APPEND BLANK REPLACE Name WITH P.Name, Address WITH P.Address @ 5,0 SAY "Name...." GET Name @ 6,0 SAY "Address." GET Address READ CLEAR GETS ENDDO SELECT SECONDARY USE SELECT PRIMARY APPEND FROM Main.$$$ USE * EOF: Update.cmd To perform the periodic packing procedure, you may use either the PACK or COPY commands: Using the PACK command: USE <file> PACK INDEX ON <exp> TO <indexfile> Using the COPY command to pack: USE <origfile> COPY TO <tempfile> USE DELETE FILE <origfile> RENAME <tempfile> TO <origfile> USE <origfile> INDEX ON <exp> TO <indexfile> >>> INDEX ON It is possible to INDEX on a field which is not in the currently selected work area when two databases are in use. It makes no sense to do this and the index file which is created will be useless, but versions 2.4, 2.41 and 2.43 do not trap this as an error. In the following example, Parts contains Partnum and Orders contains Ordernum. SELECT PRIMARY USE Parts SELECT SECONDARY USE Orders INDEX ON Partnum to Ndx1 After the INDEX ON command has been executed, dBASE II 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 >>> INDEXing with $ (substring) function If you use the $ (substring) function with no length parameter as part of an INDEX expression, dBASE II will drop off the last character or characters in the INDEX expression. Therefore, you will not be able to FIND records INDEXed in this manner. For example, INDEX ON $( Field1, 7 ) + Field2 + Field3 TO Test STORE $( Field1, 7 ) + Field2 + Field3 TO key FIND "&key" will result in a "NO FIND". The problem can be overcome if you include the length parameter in the $ (substring) statement, as follows: INDEX ON $( Field1, 7, 2 ) + Field2 + Field3 TO Test ^____This parameter is added Additionally, dBASE II will drop off the last character or characters when you use the $ (substring) function without the length parameter in an @...SAY command. >>> INSERT BLANK Using INSERT BLANK on an indexed database places the operator into the INSERTed record in full-screen mode. Use APPEND BLANK when dealing with an open index. >>> JOIN If you wish to JOIN two database files where the sum of the number of fields in both files exceeds 32, the FIELDS phrase must be used to specify which of the fields will compose the structure of the resultant file. Otherwise, the system will lock up when attempting to USE that file. >>> JOIN, repeated use of Repeated execution of the JOIN command produces inconsistent results as described below. (1) The first JOIN will execute properly. (2) The second will only copy the fields from the primary database file to the new file. (3) The third will create a new file with all the fields from the primary database file and the first field from the secondary database file. (4) The fourth gets all but the first field from the secondary database file. This occurs even if different files are used for subsequent JOINs. Eventually a "cycle" is completed and the JOIN is executed properly again. The only consistent work-around is to QUIT and re-enter dBASE II for each JOIN. >>> Memory variable corruption The following segment of code will cause a numeric memory variable to overflow and give incorrect results: STORE 123.456 TO first STORE 12.3456 TO second DO WHILE T STORE first * second / 1.000000 TO first ENDDO The results after the program displays about two screens of output are: (1) Converts the numeric memory variable to a character memory variable. (2) Loads the character memory variable with data from other places in memory. (3) Gives the error message: "TO" PHRASE NOT FOUND STORE first * second / 1.000000 TO first CALLED FROM A:NUMTRASH.PRG CORRECT AND RETRY (Y/N)? >>> Memory variables with long names Memory variable names are limited to 10 characters, but creating a variable whose name exceeds this limitation is not trapped as an error. Instead, the variable name is truncated to the first 10 characters. Subsequent references the variable may only use the first 10 characters or an error message will result. For example: . STORE 5 TO variable123 ^----- The variable name will be truncated here. . ? variable123 *** SYNTAX ERROR *** ? ? variable123 <---- Variable123 does not exist in memory, . ? variable12 <---- but Variable12 does. 5 >>> Memory variables, Changing data types of dBASE II does not support changing a memory variable type in the following example: STORE 5 TO number STORE STR(number,2) TO number ? "Number is",number This set of steps will result in: Number is 0 Instead of the expected: Number is 5 The reason for the discrepancy is that the value of 'number' is being used at the same time it is being changed. To work around this problem, use a temporary memory variable in the following manner: STORE 5 TO number STORE number TO temp STORE STR(temp,2) TO number 6 >>> MODIFY STRUCTURE and header corruption On the IBM PC, with a database file of many fields (28 or more) the following sequence in MODIFY STRUCTURE will not insert a blank field in the proper place: . USE <datafile> . MODIFY STRUCTURE {Press the following control characters: Ctrl-C Ctrl-N Ctrl-T Ctrl-W . MODIFY STRUCTURE {Now, press the following: Ctrl-N {This will insert a blank field in some other part of the database structure Successive MODIFY STRUCTURE commands will cause Ctrl-N to exhibit one or more of the following: insert many blank fields at one time, paint the screen with graphics characters, lock up the computer, or reboot the operating system. >>> MODIFY STRUCTURE procedures The following is the recommended procedure to MODIFY the structure of a database file containing records. RENAME <Yourfile> TO Temp USE Temp COPY STRUCTURE TO <Yourfile> USE <Yourfile> MODIFY STRUCTURE APPEND FROM Temp DELETE FILE Temp >>> Parentheses Limitations An expression with eight nested parentheses followed by LIST STATUS will hang the computer. For example: STORE "ABCDEF " to mem1 STORE STR(((INT(((LEN(TRIM(mem1)))+1)/2))-1),1) to mem2 LIST STATUS This may be due to a nesting limitation or to some limitation in the LIST STATUS command. >>> QUIT TO on Wang PC QUIT TO does not work on the WANG-PC. A system error, "Specified command search directory bad," is displayed and the user is left at a DOS prompt. >>> QUIT TO with an ALTERNATE file open On the T.I. PROFESSIONAL with MS-DOS 2.11 or 2.12 , if a QUIT TO command is issued when an ALTERNATE file is open, the QUIT TO will work the first time but not subsequently. Upon returning to dBASE II and executing a QUIT TO or QUIT, the error message "UNASSIGNED FILE #" appears and control returns to the dot prompt. dBASE II is now locked into an endless loop and cannot be exited without performing a warm boot. The way to avoid this problem is to close the ALTERNATE file prior to issuing the QUIT TO command. The preferred method of operation is to close all files before QUITting TO an external program. >>> READ resetting the EOF flag The EOF flag will be set to false whenever any key but the Return key is pressed in response to a READ command. The following command sequence illustrates this. USE Names INDEX Zipcode GO BOTTOM SKIP * The file pointer is at the end-of-file and * the following ? command will return a value of .T. ? EOF * * But, in response to a READ command... STORE "1" TO choice @ 10,10 GET choice READ NOUPDATE * If any key but a Return is pressed, * the following ? command will return a value of .F. ? EOF >>> REINDEX on a database file with no index Issuing the REINDEX command on a database file that does not have an open index will not display an error message. >>> REPLACE ALL 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 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' 3 records replaced . LIST 2 b 3 c 1 d 4 d 5 d The manual 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. 7 >>> REPLACE and deleted records It is not possible to REPLACE information in a record that has been marked for deletion. For example: REPLACE <field> WITH <exp> FOR * will always result in 00000 REPLACEMENT(S) no matter how many records are marked for deletion. >>> REPORT FORM and SET DELETED ON or OFF The REPORT FORM ignores the status of SET DELETED, and never prints records that are marked for deletion. There is no known work-around for this problem short of writing a dBASE command file to print the report. The dGEN utility provided on the 2.43 Utilities disk contains a FORMGEN program that is designed to do just this. Refer to your 2.41 documentation update for complete instructions. >>> REPORT FORM with SET MARGIN TO The 8-bit version of the dBASE II REPORT FORM command will print the page, subtotal, and total starting in column 0 no matter what the margin is set to. Setting the margin to 25 will still make the format look like this: Page no. 00001 06/12/84 column 1 column 2 * sub1 FIRST FIRST 99.99 ** Subtotal ** 99.99 ** Total ** 99.99 The 16-bit version of dBASE II will correctly line everything up under the date. >>> REPORT FORM, numeric overflow on large reports Large REPORT FORMs of mixed data type can generate a line of asterisks ("***") when a numeric field is totaled. The overflow on the numeric field is usually positioned on a far right column of the report. Moving the totaled column further to the left may clear up the overflow problem. >>> SET FORMAT TO <filename> and EDIT (1) When using the EDIT command with an open format file, Ctrl-U will not function as the delete toggle. To work around this problem, use a logical memory variable to store the status of each record. For example: USE Fileone SET FORMAT TO Edit STORE F TO is:deleted DO WHILE .NOT. EOF IF * STORE T TO is:deleted ELSE STORE F TO is:deleted ENDIF EDIT # IF is:deleted DELETE ENDIF ENDDO The format file, Edit.fmt, must contain an @...SAY...GET statement for each desired field as well as a command similar to the following: @ x,y SAY "Delete this record? [Y/N] " GET is:deleted (2) The documentation (Version 2.3 to 2.4 Change Summary) states that SET FORMAT TO can be used in conjunction with CREATE, but this is incorrect. If a format file is open at the time of a CREATE, the error message "VARIABLE CANNOT BE FOUND" will be displayed if you answer "Y" to the prompt, "INPUT DATA NOW (Y/N)?" >>> SET MARGIN SET MARGIN TO will not set the margin on line zero (that is, @ 0,<col> SAY) when going to the printer. However, all other lines following line zero will be printed at the new margin setting. >>> SET MARGIN If a MARGIN is SET and FORMAT is SET TO PRINT, multiple @...SAY's to the same line will include the margin setting between them. For example: SET MARGIN TO 7 SET FORMAT TO PRINT @ 10,1 SAY "Hello " @ 10,6 SAY "there" Hello there ^------ the second word should print here This result occurs as well when using relative column positioning with $. >>> Sidekick and dBASE II incompatibility If the IBM PC software product SideKick is loaded along with dBASE II and a Ctrl-C is typed in either the full screen mode, MODIFY COMMAND, or with @...GET...READ statements, it will drop out of dBASE II and return immediately to the operating system. Use the PgDn key instead of Ctrl-C.