home *** CD-ROM | disk | FTP | other *** search
/ Shareware Overload / ShartewareOverload.cdr / database / db3tips.zip / CISNOTES.DB3
Text File  |  1986-03-19  |  74KB  |  1,923 lines

  1. «RM80» >>> Closing Database Files
  2.  
  3.  Do not swap data disks without first closing all the open files on the original
  4. disk.  Not doing so will cause the loss of data in buffers, and will also write
  5. a new entry in the directory of the new disk.  USE will close the currently
  6. SELECTed database file and CLOSE DATABASES will close all database files in all
  7. work areas.  CLEAR ALL also closes all open database files and will also release
  8. all memory variables.  QUIT closes all files, releases all variables, and exits
  9. dBASE III.  Choose one of these commands to close your files before swapping
  10. data disks.
  11.  
  12.  >>> COPY TO <filename> [SDF/DELIMITED [WITH <delimiter>]]
  13.  
  14.  (1) COPY TO <filename> DELIMITED does not enclose logical fields with the
  15.       specified delimiters.   Numeric and date fields are also treated this
  16.        way. Date fields go out in the format YYYYMMDD.
  17.  
  18.  (2) COPY TO <filename> DELIMITED WITH , encloses the character fields in
  19.      commas and separates the fields with another comma. This command behaves
  20.      differently from dBASE II as shown below:
  21.  
  22.      In dBASE II:
  23.  
  24.      . USE file1
  25.      . COPY TO file2 DELIMITED WITH ,
  26.  
  27.      will result in:
  28.  
  29.      SANTA,CLAUS,NORTH POLE,ALASKA
  30.  
  31.   In dBASE III:
  32.      . USE file1
  33.      . COPY TO file2 DELIMITED WITH ,
  34.  
  35.      will result in:
  36.  
  37.      ,SANTA,,,CLAUS,,,NORTH POLE,,,ALASKA,
  38.  
  39.  
  40.  >>> COPY
  41.  
  42. Many users find it difficult to COPY a single record or a block of records from
  43. one database file to another.  The method is quite simple.  When you LOCATE the
  44. record or the first record of the block you wish to COPY to the second database
  45. file, first COPY it to a temporary database file, and then APPEND the temporary
  46. into the secondary database file.  To specify the group of records to COPY,
  47. define a scope or use a WHILE condition.  If you only want the current record,
  48. use the scope NEXT 1.  The NEXT scope always begins at the current record and
  49. proceeds for as many records as are specified, so NEXT 1 refers to the current
  50. record only.  If, for example, you want to COPY five records including the
  51. current record, your scope would be NEXT 5.
  52.  
  53.  The following demonstrates this concept:
  54.  
  55.  SET SAFETY OFF
  56.  USE File1
  57.  SELECT 2
  58.  USE File2
  59.  SELECT 1
  60.  * ---Move the record pointer to the record you want
  61.  * ---to COPY to the secondary database file.
  62.  LOCATE FOR Name = "Henry"
  63.  COPY NEXT 1 TO Temp
  64.  SELECT File2
  65.  APPEND FROM Temp
  66.  SELECT File1
  67.  
  68.  If the grouping of records you want to COPY to the secondary database file is
  69. based on a value of a field or an expression, then you should use a WHILE
  70. condition.  By specifying a WHILE condition you can COPY from the current record
  71. until the condition is not true.
  72.  
  73.  When you use this technique, be sure to SET SAFETY OFF so that you do not have
  74. to answer the overwriting query that will accompany each COPY TO Temp once Temp
  75. is created.
  76.  
  77.  
  78.  >>> COPY FILE <source filename> TO <target filename>
  79.  
  80.  The COPY FILE command copies files in 512 byte blocks; whereas, the COPY TO
  81. command will copy a .DBF file until the end-of-file. Therefore, the COPY FILE
  82. command will usually create a slightly larger file than the COPY TO command.
  83. However, the COPY FILE is faster.
  84.  
  85.  
  86.  >>> COPY STRUCTURE EXTENDED & CREATE FROM
  87.  
  88.  COPY STRUCTURE EXTENDED and CREATE FROM are fully implemented in dBASE III
  89. although not documented.  A brief description is given below.
  90.  
  91.  1) COPY STRUCTURE EXTENDED creates a file in whch the field
  92.     names become the contents of one record.  The syntax for
  93.     this COPY option is:
  94.  
  95.            COPY STRUCTURE EXTENDED TO <new file>
  96.  
  97.  2) CREATE FROM forms a new database (.DBF) file in which the
  98.     structure is determined by the contents of a file created
  99.     with COPY STRUCTURE EXTENDED.  The syntax is:
  100.  
  101.            CREATE <new file> FROM <structure extended file>
  102.  
  103.  
  104.  >>> CREATE/MODIFY REPORT
  105.  
  106.  When you get the error message "Internal error - bucket overfilled" while in
  107. CREATE REPORT or MODIFY REPORT, you have too many characters in the report. The
  108. maximum number of characters, or bucket size, is 1,440 bytes.  This includes the
  109. number of characters in the following list:
  110.  
  111.       Report heading          - plus one byte for each line
  112.       Subtotal heading(s)     - plus one byte for each line
  113.       Subtotal expression(s)  - plus one byte for each expression
  114.       Field heading(s)        - plus one byte for each line
  115.       Field expression(s)     - plus one byte for each expression
  116.  
  117.  The extra byte is a null terminator for each expression and heading. When there
  118. are multiple lines in a heading, dBASE III separates them with a semicolon in
  119. the .FRM file.
  120.  
  121.  
  122.  >>> Date conversion from dBASE II
  123.  
  124.  The dBASE BRIDGE manual (pages 23-24) lays out an elaborate scheme for
  125. converting dBASE II "dates" to dBASE III date fields. A much easier way is to
  126. simply convert the dBASE II database file to a dBASE III file and modify the
  127. structure from character to date field. All dates stored in a dBASE II character
  128. field as "MM/DD/YY" will directly convert to a dBASE III date field.
  129.  
  130.  
  131.  >>> Dates that are blank
  132.  
  133.  CTOD() and DTOC() are intended to be inverse functions.  That is, if DTOC(date)
  134. = char, then CTOD(char) = date.  This is true in all circumstances except when
  135. the date is blank and the character string is " / / ".  To detect a blank date,
  136. you must use the DTOC() function rather than CTOD().  For example:
  137.  
  138.       reg_date = CTOD("11/09/84")
  139.       ? reg_date = CTOD("11/09/84")
  140.       .T.
  141.       ? DTOC(reg_date) = "11/09/84"
  142.       .T.
  143.       * ---With a blank date the following occurs:
  144.       blank_date = CTOD("  /  /  ")
  145.       ? blank_date = CTOD("  /  /  ")
  146.       .F.
  147.       ? DTOC(blank_date) = "  /  /  "
  148.       .T.
  149.  
  150.   As is evident from the example, the blank date is handled differently than the
  151. non-blank date.
  152.  
  153.  
  154.  >>> dBRUN (Developer's Release)
  155.  
  156.  (1) Pages 1-32 and 1-33 of the RunTime+ documentation state that the dBRUN disk
  157. contains the files DBRUN.EXE and DBRUN.OVL.  In fact, a directory of the disk
  158. shows DBRUN.COM and DBRUN.OVL. DBRUN.EXE is a hidden file and will not show up
  159. when you do a DIR or LIST FILES LIKE *.*.
  160.  
  161.  (2) On page 1-43 of the same manual, the user is instructed to rename the
  162. DBRUN.EXE to a name that reflects the RunTime+ application.  However, the
  163. DBRUN.EXE file is hidden and therefore cannot be renamed.  The correct procedure
  164. is to rename the executable loader file, DBRUN.COM file, which is not hidden.
  165. >>> Debugging tip
  166.  
  167.  The RETURN and CANCEL commands will release all PRIVATE memory variables
  168. whenreturning to the dot prompt.  This can make debugging difficult with
  169. versions1.0 and 1.1 as you may want to check the status of variables used by the
  170. program.  The following debugging utility can be set up as a command file. This
  171. utility, called Dot.PRG, will allow you to interactively enter commands, such as
  172. LIST MEMORY and LIST STATUS.
  173.  
  174.  You can insert the command "DO Dot" at various problem points in your program.
  175. When this command is encountered, you will be able to enter interactive commands
  176. without destroying the current environment of the program at runtime.  Once the
  177. program is fully debugged, you can remove the "DO Dot" command lines.
  178.  
  179.       * Dot.PRG
  180.       DO WHILE .T.
  181.          ACCEPT 'DOT  ' TO command
  182.          IF LEN( TRIM(command) ) = 0
  183.             EXIT
  184.          ENDIF
  185.          &command
  186.       ENDDO
  187.       RETURN
  188.  
  189.  >>> DELETE
  190.  
  191.  There are occasions when you want to DELETE records in one database file based
  192. on values in a related database file.  The following code fragment demonstrates
  193. how this can be done. Entries in the Master database file are DELETEd if there
  194. are no matching transactions in the Trans database file.
  195.  
  196.  SELECT 1
  197.  USE Master
  198.  SELECT 2
  199.  USE Trans INDEX Customer
  200.  SELECT Master
  201.  SET RELATION TO key INTO Trans
  202.  DELETE ALL FOR Customer <> Trans->Customer
  203.  
  204.  The same technique can be used to DELETE all transactions in the Trans database
  205. file for entries that have no Master record.  The Master database file would
  206. have to be INDEXed on the linking expression, a RELATION SET from the Trans work
  207. area INTO the Master work area, and the DELETE command issued from the Trans
  208. work area.
  209.  
  210.  >>> Demonstration Disk (RunTime+)
  211.  
  212.  In the Developer's Release of dBASE III, the dBRUN programs from the
  213. Demonstration Disk are not compatible with the full system. Code crunched with
  214. DBC.COM from the Demonstration Disk can only be run with dBRUN from the
  215. Demonstration Disk.  Code crunched with DBC.COM from the Developer's Disk can
  216. only be run with the full dBASE III system or the dBRUN disk, purchased
  217. separately.
  218.  
  219.   The error message:
  220.  
  221.       No database is in USE.  Enter filename:
  222.  
  223.   is a common indicator that the incorrect dBRUN or dBC is being used.
  224.  
  225.  
  226.   >>> DISPLAY and LIST
  227.  
  228.   The DISPLAY and LIST commands are documented inthe manual as not having a
  229. FIELDS clause as part of the syntax, while the ASSIST and HELP menu options
  230. assume the FIELDS clause is required. dBASE III will accept either syntax for
  231. these two commands.
  232.  
  233.  >>> Duplicate Keywords in Config.DB
  234.  
  235.  If two or more COMMAND = <value> lines are contained in the Config.DB file,
  236. only the last COMMAND will execute.  This is true of any duplicate <keyword> =
  237. <value> entry in the Config.DB file, with the exception of DELIMITERS, which can
  238. legitimately have two entries.  This is true for versions 1.0 and 1.1 of dBASE
  239. III.
  240.  
  241.  >>> FILE() function
  242.  
  243.  The FILE() function only searches the current directory.  SET PATH TO does not
  244. affect this function.  If other directories are to be searched, they must be
  245. supplied to the function.  For example,
  246.  
  247.       * ---This will not find Data.dbf, if Data.dbf is in the
  248.       * ---subdirectory ACCTS.
  249.       SET PATH TO \DBASE\ACCTS
  250.       IF FILE( "DATA.DBF" )
  251.          DO Process
  252.       ENDIF
  253.  
  254.   Workaround:
  255.  
  256.       * ---This method will work.
  257.       mpath = "\DBASE\ACCTS\"
  258.       SET PATH TO &mpath
  259.       IF FILE( mpath + "DATA.DBF" )
  260.          DO Process
  261.       ENDIF
  262.  
  263.  >>> CTOD() Function
  264.  
  265.  The dBASE III Reference Manual does not clearly state that the CTOD() function
  266. will convert invalid dates to valid dates.  The day is adjusted first.
  267.  
  268.       ? CTOD("02/29/85")
  269.       03/01/85  <------------ Extra day is added to month.
  270.       ? CTOD("02/29/84")
  271.       02/29/84  <------------ Leap years are correct.
  272.  
  273.  If the month is invalid, it is divided by twelve and the year is adjusted. For
  274. example:
  275.  
  276.       ? CTOD("13/01/84")
  277.       01/01/85  <------------ Extra month is added to year.
  278.       ? CTOD("12/32/84")
  279.       01/01/85  <------------ Extra day is added to month,
  280.                               extra month is added to year.
  281.       ? CTOD("99/99/62")
  282.       06/23/70
  283.  
  284.   >>> @...GET...RANGE
  285.   RANGE is used in conjunction with @...GET to specify an acceptable continuous
  286.  set of input values to date or numeric fields.  The RANGE is initialized by
  287.  specifying lower and upper bounds (inclusive) which may be literal values,
  288.  memory variables, or expressions.  For example:
  289.  
  290.   1) Literal values:
  291.       @ 10,10 GETvar1  RANGE 1,9
  292.       @ 11,10 GET mdate RANGE CTOD('12/12/84'),CTOD('12/12/85')
  293.   2) Memory variables:
  294.       STORE 1 TO low
  295.       STORE 9 TO high
  296.       @ 10,10 GET var1 RANGE low,high
  297.  
  298.       STORE CTOD('12/12/84') TO low_date
  299.       STORE CTOD('12/12/85') TO high_date
  300.       @ 10,10 GET mdate RANGE low_date,high_date
  301.   3) Expressions:
  302.       @ 10,10 GET var1  RANGE low+365,high+(365*10)
  303.       @ 11,10 GET mdate RANGE DATE(),high_date+120
  304.  
  305.   Entries outside of the defined range will generate an error message and input
  306.  will be prompted until a valid entry is made.
  307.  
  308.   >>> @...GET and READ
  309.   (1) If an attempt is made to @...GET memvar PICTURE "999.99" and the memory
  310.  variable is not initialized with the number of decimal places specified in the
  311.  PICTURE clause, the GET display will not show the decimal digits for input.
  312.  Entering a decimal point will exit the GET. For example:
  313.  
  314.      * ---Set up numeric input.
  315.      num = 0
  316.      @ 10,10 SAY "Enter number " GET num PICTURE "999.99"
  317.      READ
  318.      *
  319.      * ---After entering a decimal point during the READ,
  320.      * ---the GET will display the following:
  321.  
  322.          Enter number :  0.  :
  323.  
  324.   To properly input numeric memory variables with decimal digits using
  325.  @...GET...PICTURE, initialize the memory variable with the number of decimal
  326.  digits used in the PICTURE clause.  For example:
  327.  
  328.      * ---The following command line assigns num with
  329.      * ---the same number of decimal digits as found
  330.      * ---in the PICTURE clause.
  331.      num = 0.00
  332.      @ 10,10 SAY "Enter number " GET num PICTURE "999.99"
  333.      READ
  334.  
  335.   (2) When using @...GET and READ cetain keys will terminate the READ. The
  336.  following table shows which keys do so and where in the pending GETs the key
  337.  will terminate the READ.
  338.  
  339.      Key:        The READ will terminate at:
  340.      ----------- ---------------------------
  341.      Backspace    First character of first GET
  342.      Left arrow   First character of first GET
  343.      Right arrow  Last character of last GET
  344.      Up arrow     First GET
  345.      Down arrow   Last GET
  346.      Esc          Anywhere
  347.      F1           Anywhere
  348.      Ctrl-[       Anywhere
  349.      Ctrl-Q       Anywhere
  350.      Ctrl-W       Anywhere
  351.      Ctrl-Home    Anywhere
  352.      Ctrl-End     Anywhere
  353.      PgUp         Anywhere
  354.      PgDn         Anywhere
  355.      Ctrl-PgUp    Anywhere
  356.      Ctrl-PgDn    Anywhere
  357.      Alt 0-9      Anywhere
  358.  
  359.   >>> @...GET...PICTURE
  360.   Assuming a memvar is initialized with zero (that is, memvar = 0), when the
  361.  user types a period at an @...GET memvar PICTURE "9999.99", dBASE will proceed
  362.  to the next command line.  This will not occur when the memory variable is
  363.  initialized to two decimal places (that is, memvar = 0.00).  Only the integer
  364.  portion of the number just entered will be stored to memvar if the period is
  365.  typed.
  366.  
  367.   >>> @...GET...PICTURE
  368.  
  369.   The function "@B" is used with the @...SAY...GET statement to left-justify
  370.  variables of numeric type.  It is most useful when SAYing a numeric field or
  371.  memory variable that is more easily understood as a character string, such as
  372.  a part number.  Use of this FUNCTION with GET, however, causes a slight change
  373.  in the way numeric variables are read from the screen that may cause some
  374.  difficulties.
  375.   A numeric memory variable will default to a length of ten digits when
  376.  initialized; however, if you are using the PICTURE function "@B" in an @...GET
  377.  statement, a numeric memory variable will GET the width of the memory variable
  378.  exactly as initialized, even if a template symbol is used.  Initializing a
  379.  memory variable to zero will cause the GET statement to display one zero on
  380.  the screen.  A READ command will allow one digit only to be entered to the
  381.  memory variable.
  382.   This occurs whether the memoy variable is initialized to 0 or 0000.  For
  383.  example:
  384.  
  385.       SET DELIMITERS ON
  386.       w = 1234
  387.       x = 0
  388.       y = 0000
  389.       @  9,0 GET w PICTURE "@B9999"
  390.       @ 10,0 GET x PICTURE "@B9999"
  391.       @ 11,0 GET y PICTURE "@B9999"
  392.  
  393.  
  394.   will produce:
  395.  
  396.       :1234:
  397.       :0:
  398.       :0:
  399.  
  400.   A READ command will allow four characters to be entered in the first
  401.  variable, but only one character in the next two variables.  If the "@B"
  402.  function is used, initialize the memory variable to the proper length or the
  403.  input may be truncated.
  404.  
  405.   >>> @...SAY...PICTURE
  406.   To display a dollar-sign character ("$") in front of a numeric value and not
  407.  have the possibility of a lot of "$"s filling the blank areas, do the
  408.  following:
  409.  
  410.       * ---To display a single "$".
  411.  
  412.       STORE 123.56 TO num
  413.       @ 10,10 SAY "$"
  414.       @ 10,11 SAY num PICTURE "99,999.99"
  415.  
  416.       This will generate:
  417.  
  418.                 $  123.56
  419.  
  420.       * ---The other option available is:
  421.       STORE 123.56 TO num
  422.       @ 10,10 SAY num PICTURE "$$,$$$.$$"
  423.  
  424.       This will generate:
  425.  
  426.                 $$$123.56
  427.  
  428.   >>> @...SAY using relative addressing
  429.   We use the '$' function in dBASE II to control relative screen addressing
  430.  with the @...SAY function.  For example, you can have a command file print the
  431.  contents of a datafile to the screen as follows:
  432.  
  433.       * ---This is dBASE II syntax.
  434.       USE <datafile>
  435.       DO WHILE .NOT. EOF
  436.       *
  437.          @ 5,  5 SAY <Field1>
  438.          @ $+1,$ SAY <Field2>
  439.          @ $+1,$ SAY <Field3>
  440.          @ $+1,$ SAY <Field4>
  441.          SKIP
  442.       *
  443.       ENDDO [while .not. eof]
  444.  
  445.   The dBASE III utility, dCONVERT, is used to convert dBASE II programs,
  446.  datafiles, etc. to dBASE III formats.  dCONVERT does not change the '$'
  447.  function to ROW() and COL(); it leaves it alone.  However, this will not cause
  448.  any problems when executing the code in dBASE III.  dBASE III will treat the
  449.  '$' function as a relative addressing function.
  450.  
  451.   >>> APPEND FROM <filename> [SDF/DELIMITED [WITH <delimiter>]]
  452.   The DELIMITED form of the APPEND FROM command should be documented as having
  453.  a WITH clause.  WITH is not mentioned in the reference section. Below are a
  454.  few examples:
  455.  
  456.   Example 1. To read a comma delimited file in which the
  457.              character strings are enclosed in double quotes:
  458.  
  459.              APPEND FROM <filename> DELIMITED
  460.           or
  461.              APPEND FROM <filename> DELIMITED WITH "
  462.  
  463.   Example 2. To read a comma delimited file in which the
  464.              character strings are enclosed in single quotes:
  465.  
  466.              APPEND FROM <filename> DELIMITED WITH '
  467.  
  468.   Example 3. To read a comma delimited file in which the
  469.              character strings are not enclosed at all:
  470.  
  471.              dBASE III CANNOT READ A FILE OF THIS FORMT!
  472.  
  473.   Also, the syntax of the APPEND command does not include a WHILE option as the
  474.  manual indicates.  The correct syntax is
  475.  
  476.       APPEND FROM <file name> [FOR <condition>]
  477.              [SDF/DELIMITED [WITH <delimiter>]]
  478.  
  479.   APPEND FROM <textfile> SDF expects records in te text file to be terminated
  480.  with a carriage return/line feed (0DH 0AH) pair, in this order.  If the order
  481.  is reversed (0AH 0DH), dBASE III ignores the character following the carriage
  482.  return.  This causes the first character of every record (after the first
  483.  record) to be missed in the resultant database file.
  484.  
  485.  
  486.  >>> Numeric fields with decimal places
  487.  
  488.  Although not documented, dBASE III expects the user to allow for a leading
  489. digit and a decimal point on numeric fields containing decimal places.  For
  490. example, a numeric field of two decimal places should not be defined any smaller
  491. than four digits in length--one position for the leading digit, one position for
  492. the decimal point, and two positions for the two decimal places.
  493.  
  494.  If the structure for a numeric field does not allow for a leading digit (such
  495. as, a width of three and two decimal places), numeric input to the numeric field
  496. will always be stored as zero.  Also, if other numeric fields follow this field,
  497. they might automatically be zeroed out when numeric data is entered to the first
  498. field.
  499.  
  500.  >>> Numeric input of large numbers
  501.  
  502.  If a variable is initialized to zero, dBASE III does not allow input larger
  503. than 10 digits when using the @...GET command, even if the PICTURE clause is
  504. used.  For example:
  505.  
  506.      x = 0
  507.      @ 5,5 SAY "Enter digits" GET x PICTURE "99999999999"
  508.      *      (There are eleven 9's) ----------^
  509.      READ
  510.  
  511.     The display is:
  512.  
  513.             Enter digits           0
  514.  
  515.     If an eleven digit value is entered, the display is:
  516.  
  517.              Enter digits  **********  (10 asterisks)
  518.  
  519.  This can be avoided by initializing 'x' to a value greater than ten digits
  520. (such as, 1000000000).  This problem does not occur if a field is used rather
  521. than a memory variable.
  522.  
  523.  >>> ON KEY
  524.  
  525.  If you have set the ON KEY command and are executing any command that takes
  526. some time to process, such as LIST or REPORT FORM, pressing a key will not
  527. interrupt the command being executed.  Instead the key pressed will be stored in
  528. the typeahead buffer and ON KEY will execute when that command is finished.
  529.  
  530.  
  531.  >>> PARAMETERS, passing Fields
  532.  
  533.  In the documentation concerning PARAMETERS when used in conjunction with the DO
  534. <filename> [WITH <parameter list>] command, page 4-76 of the version 1.0 manual
  535. states, "A passed parameter may be any legitimate expression."  Also, in the
  536. Glossary (page 7-3) the definition for Expression is, "Expression may consist of
  537. a field, a memory variable, a function, a constant, or any combination thereof."
  538.  However, when a DO is invoked with a field in the parameter list, dBASE III
  539. will give the message, "Variable not found."  In order to use a field name in
  540. the parameter list, you must use the Alias -> Fieldname form.  For example:
  541.  
  542.       USE Filea
  543.       DO <Filename> WITH Filea -> Field1
  544.  
  545.   will work, but the following will not.
  546.  
  547.       USE Filea
  548.       DO <Filename> WITH Field1
  549.  
  550.  
  551.  >>> Reserved Device Names in MS-DOS
  552.  
  553.  The MS-DOS manual specifies that certain names have a special meaning to
  554. MS-DOS.  Do not use these reserved device names as dBASE III filenames: CON,
  555. AUX, COM1, COM2, LPT1, PRN, LPT2, LPT3, or NUL.  This applies to database files,
  556. index files, command files, format files, or form files.  Various error messages
  557. will result when files with any of these names are accessed.
  558.  
  559.  
  560.  >>> Reserved words
  561.  
  562.  Page 1-138 of the tutorial in the first edition of the manual uses a sample
  563. routine which creates a memory variable with the name 'continue.' Since this is
  564. a reserved word, dBASE III will give the message, "No database in USE, enter
  565. filename."  dBASE III is assuming you intend to CONTINUE on a LOCATE command.
  566. This will only happen if you use the <variable> = <value> frm of assignment;
  567. dBASE III will execute correctly when you use the STORE <value> TO <variable>
  568. form.  Other words that will not work with the first syntax are AVERAGE, COUNT,
  569. and SUM.
  570.  
  571.  >>> ROW(), COL()
  572.  
  573.  After a READ, the ROW() function always returns 24; however, the COL() function
  574. does not change.  For example:
  575.  
  576.       SET TALK OFF
  577.       var = SPACE(2)
  578.       @ 5,40 GET var
  579.       ? ROW(), COL()      <--- This returns 6 and 3.
  580.       READ
  581.       ? ROW(), COL()      <--- This returns 24 and 3.
  582.  
  583.  
  584.  >>> RUN (or !)
  585.  
  586.  The RUN command requires that COMMAND.COM be in the boot drive or the directory
  587. indicated by SET COMSPEC.  Otherwise, the incorrect error message "Insufficient
  588. memory" is displayed.
  589.  
  590.  
  591.  >>> RUN COMMAND
  592.  
  593.  You can get the equivalent to Framework's DOS Access in dBASE III by issuing
  594. RUN COMMAND.  This will leave you at the DOS operating system level and will
  595. allow you to enter any DOS commands.  To get back to the dBASE III dot prompt,
  596. type EXIT.
  597.  
  598.  
  599.  >>> SET ALTERNATE TO
  600.  
  601.  dBASE III will not send a linefeed (that is, CHR(10)) to an alternate file
  602. (Word Perfect looks for this linefeed character in its mail merge program). The
  603. following command file:
  604.  
  605.       SET ALTERNATE TO x
  606.       SET ALTERNATE ON
  607.       ?? "first LF"
  608.       ?? CHR(10)
  609.       ?? "second LF"
  610.       SET ALTERNATE OFF
  611.       CLOSE ALTERNATE
  612.  
  613.  will generate the following test file:
  614.  
  615.       first LFsecond LF
  616.  
  617.  As you can see, there is no linefeed in the file.
  618.  
  619.  
  620.  >>> SET COLOR
  621.  
  622.  (1) To get enhanced video to be black on black, use the command SET COLOR TO
  623. x/y,0+/0.  Black on black is frequently used to allow user input without
  624. displaying the characters on the screen, as with entry of a password.
  625.  
  626.  (2) The command:
  627.  
  628.       SET COLOR TO  ,<cr>
  629.  
  630.  will produce black on black, even if there is no space after the comma.
  631.  
  632.  (3) The asterisk (*) used with the SET COLOR command allows you to have
  633. blinking characters on thescreen.  The asterisk must be used in conjunction with a color parameter.  For example:
  634.  
  635.       SET COLOR TO 6*/1,7/4,6
  636.  
  637.  or:
  638.  
  639.       SET COLOR TO GR*/B,W/R,GR
  640.  
  641.  
  642.  >>> SET COLOR TO on the Compaq computer
  643.  
  644.  SET COLOR TO U on the Compaq computer will not generate underlining. Instead,
  645. SET COLOR TO U and SET COLOR TO I give quarter intensity. Using U+ or I+ will
  646. generate half intensity. You will not get the monochrome attributes, because the
  647. Compaq monitor is operating as if it where color.
  648.  
  649.  
  650.  >>> SET CONSOLE ON/OFF
  651.  
  652.  The SET CONSOLE ON/OFF command behaves differently in dBASE III than it does in
  653. dBASE II.  Specifically, it has no effect when issued at the dot prompt, and if SET CONSOLE OFF is issued in a command file that neglects to SET CONSOLE ON, dBASE III will automatically set the console back on upon the termination of execution of that file.  This includes normal termination as well as termination by means of pressing the escape key.
  654.  
  655.  
  656.  >>> SET DEBUG ON
  657.  SET DEBUG ON overrides SET CONSOLE OFF and output will be echoed to the screen.
  658.  
  659.  >>> SET DELETED
  660.  
  661.  SET DELETED in dBASE III applies to all commands, unlike dBASE II, where
  662. certain commands ignore the status of SET DELETED.  In dBASE III you are
  663. permitted to COPY, APPEND, and REPORT deleted records if DELETED is set OFF.
  664.  
  665.  
  666.  >>> SET DOHISTORY ON/OFF (Developer's Release)
  667.  
  668.  If your dBASE III Developer's Release Reference Manual does not contain page
  669. 4-115A in the Commands section which explains the use of SET DOHISTORY, the
  670. following documents the command:
  671.  
  672.  SET DOHISTORY determines whether or not commands from command files are
  673. recorded in HISTORY.
  674.  
  675.  Syntax:          SET DOHISTORY ON/OFF
  676.  
  677.  Defaults:          SET DOHISTORY is normally OFF
  678.  
  679.  Usage:           When SET DOHISTORY is ON, commands that were
  680.                  executed from within command files are stored in
  681.                  HISTORY.  You can then edit these in full-screen
  682.                  edit mode and execute them.
  683.  
  684.                  Note that SET DOHISTORY has no effect on commands
  685.                  you issue from the dot prompt.
  686.  
  687.  Tips:            In conjunction with SUSPEND, SET DOHISTORY is
  688.                  useful for debugging.  However, because SET
  689.                  DOHISTORY slows down command file execution, use
  690.                  it only when debugging.
  691.  
  692.  See Also:        DISPLAY HISTORY, LIST HISTORY, RESUME, SET DEBUG,
  693.                  SET ECHO, SET HISTORY, SET STEP, SUSPEND
  694.  
  695.  >>> SET FILTER TO
  696.  
  697.  (1) The SORT command will only sort those records that meet the filter
  698. condition.  The INDEX command will index all records in the file whether or not
  699. they meet the filter condition.  However, a FIND command will return "No find"
  700. if the key falls outside the scope of FILTER.
  701.  
  702.  (2) Some users are confused regarding the performance that may be expected when
  703. using the SET FILTER TO command.  The database file is not smaller in size when
  704. a filter is set.  Consequently, activities that access the file are not
  705. proportionately faster.  Commands that operate on the FILTERed set of records
  706. must still scan the entire database file.
  707.  
  708.  
  709.  >>> SET FORMAT TO (Developer's Release & RunTime+)
  710.  
  711.  A format file must remain unencrypted, or be worked into the .SRC file to be
  712. utilized by dBRUN.  The documentation for RunTime+ does not mention that an
  713. unencrypted format (.FMT) file may be accessed with the SET FORMAT TO command.
  714. In fact, dBRUN will process only an unencrypted format file with this command.
  715.  
  716.  >>> SET MENUS ON/OFF
  717.  
  718.  The default for SET MENUS is OFF.  However, ASSIST leaves MENUS SET ON even if
  719. they were off prior to entering ASSIST.
  720.  
  721.  
  722.  >>> SET PROCEDURE TO, PARAMETERS, PROCEDURE
  723.  
  724.  The following program and procedure files illustrate the use of parameter
  725. passing with procedures.  FUTVALUE.PRG calculates the future value of an
  726. investment and the future value of an annuity with the use of the BUSINESS.PRG
  727. procedure file.  Notice how the parameters can be passed to BUSINESS.PRG. They
  728. can either be literal numbers, expressions, or variables.  Also, notice that the
  729. PARAMETERS command is included after each PROCEDURE that receives parameters.
  730.  
  731.   LISTINGS:
  732.  
  733.       * FUTVALUE.PRG
  734.       * ------------
  735.       SET TALK OFF
  736.       SET FIXED ON
  737.       SET PROCEDURE TO  Business
  738.       *
  739.       * { Calculate future value of an investment
  740.  
  741.       result = 0.00
  742.       DO  FV  WITH  6000.00, 8.5, 4, 5, result
  743.       ? result
  744.       *
  745.       * { Calculate future value of regular deposits (Annuity)
  746.  
  747.       result = 0.00
  748.       DO  FVA  WITH  150.00, 7.0, 12, 2, result
  749.       ? result
  750.       *
  751.       CLOSE PROCEDURE
  752.       SET FIXED OFF
  753.       SET TALK ON
  754.       RETURN
  755.       * EOF: FUTVALUE.PRG
  756.  
  757.  
  758.       * BUSINESS.PRG  { Library of business procedures
  759.  
  760.       * ------------
  761.       *
  762.        PROCEDURE  FV  { Calculate future value of an investment
  763.  
  764.        PARAMETERS  amount, rate, periods, years, result
  765.         rate = rate / periods / 100
  766.         result = amount * (1 + rate)  (periods * years)
  767.         result = ROUND( result, 2 )
  768.        RETURN
  769.       *
  770.        PROCEDURE FVA { Calculate future value of regular deposits
  771.  
  772.        PARAMETERS  amount, rate, periods, years, result
  773.         rate = rate / periods / 100
  774.         result = amount * ( (1 + rate)  (periods *;
  775.                    years) - 1 ) / rate
  776.         result = ROUND( result, 2 )
  777.        RETURN
  778.       *
  779.       * EOF: BUSINESS.PRG
  780.  
  781.   OUTPUT:
  782.  
  783.        9136.77
  784.        3852.15
  785.  
  786.  The following is a procedure that demonstrates the use of MEMO fields in
  787. conjunction with @...SAY...GET:
  788.  
  789.           USE <filename>
  790.           DO WHILE .T.
  791.              APPEND BLANK
  792.              CLEAR
  793.              @ 10,10 SAY 'Field 1 = ' GET Fld1
  794.              @ 11,10 SAY 'Field 2 = ' GET Fld2
  795.              READ
  796.              IF Fld1=SPACE(10)
  797.                 EXIT
  798.              ELSE
  799.                 CHANGE NEXT 1 FIELDS Memo1
  800.              ENDIF
  801.           ENDDO
  802.           RETURN
  803.  
  804.  The screen will initially show the format specified by the @...SAY...GET.  When
  805. the last field has been entered, the screen will clear and the MEMO field will
  806. be displayed in reverse video. The user will then press Ctrl-Home and enter the
  807. full screen MEMO editing mode. When you are finished editing, a Ctrl-End will
  808. save changes or additions and return the user to the MEMO field.  A <RETURN>
  809. will proceed to the execution of the next command.
  810.  
  811.  
  812.  dBASE III Database File Structure
  813.  
  814.  The structure of a dBASE III database file is composed of a
  815.  header and data records.  The layout is given below.
  816.  
  817.  
  818.  dBASE III DATABASE FILE HEADER:
  819.  
  820.  +---------+-------------------+---------------------------------+
  821.  |  BYTE   |     CONTENTS      |          MEANING                |
  822.  +---------+-------------------+---------------------------------+
  823.  |  0      |  1 byte           | dBASE III version number        |
  824.  |         |                   |  (03H without a .DBT file)      |
  825.  |         |                   |  (83H with a .DBT file)         |
  826.  +---------+-------------------+---------------------------------+
  827.  |  1-3    |  3 bytes          | date of last update             |
  828.  |         |                   |  (YY MM DD) in binary format    |
  829.  +---------+-------------------+---------------------------------+
  830.  |  4-7    |  32 bit number    | number of records in data file  |
  831.  +---------+-------------------+---------------------------------+
  832.  |  8-9    |  16 bit number    | length of header structure      |
  833.  +---------+-------------------+---------------------------------+
  834.  |  10-11  |  16 bit number    | length of the record            |
  835.  +---------+-------------------+---------------------------------+
  836.  |  12-31  |  20 bytes         | reserved bytes (version 1.00)   |
  837.  +---------+-------------------+---------------------------------+
  838.  |  32-n   |  32 bytes each    | field descriptor array          |
  839.  |         |                   |  (see below)                    | --+
  840.  +---------+-------------------+---------------------------------+   |
  841.  |  n+1    |  1 byte           | 0DH as the field terminator     |   |
  842.  +---------+-------------------+---------------------------------+   |
  843.                                                                      |
  844.                                                                      |
  845.  A FIELD DESCRIPTOR:      <------------------------------------------+
  846.  
  847.  +---------+-------------------+---------------------------------+
  848.  |  BYTE   |     CONTENTS      |          MEANING                |
  849.  +---------+-------------------+---------------------------------+
  850.  |  0-10   |  11 bytes         | field name in ASCII zero-filled |
  851.  +---------+-------------------+---------------------------------+
  852.  |  11     |  1 byte           | field type in ASCII             |
  853.  |         |                   |  (C N L D or M)                 |
  854.  +---------+-------------------+---------------------------------+
  855.  |  12-15  |  32 bit number    | field data address              |
  856.  |         |                   |  (address is set in memory)     |
  857.  +---------+-------------------+---------------------------------+
  858.  |  16     |  1 byte           | field length in binary          |
  859.  +---------+-------------------+---------------------------------+
  860.  |  17     |  1 byte           | field decimal count in binary   |
  861.  +---------+-------------------+---------------------------------+
  862.  |  18-31  |  14 bytes         | reserved bytes (version 1.00)   |
  863.  +---------+-------------------+---------------------------------+
  864.  
  865.  
  866.  The data records are layed out as follows:
  867.  
  868.      1. Data records are preceeded by one byte that is a
  869.      space (20H) if the record is not deleted and an
  870.      asterisk (2AH) if it is deleted.
  871.  
  872.      2. Data fields are packed into records with no field
  873.      separators or record terminators.
  874.  
  875.      3. Data types are stored in ASCII format as follows:
  876.  
  877.      DATA TYPE      DATA RECORD STORAGE
  878.      ---------      --------------------------------------------
  879.      Character      (ASCII characters)
  880.      Numeric        - . 0 1 2 3 4 5 6 7 8 9     Logical        ? Y y N n T t F f
  881.  (? when not initialized)
  882.      Memo           (10 digits representing a .DBT block number)
  883.      Date           (8 digits in YYYYMMDD format, such as
  884.                     19840704 for July 4, 1984)
  885.  
  886.  DEBUGGING - program break points
  887.  The following program segment (sent in by Steve Steiner) illustrates a way of
  888. debugging programs without losing the memory variables the program is using.
  889. "DO DOT" can be placed in the problem areas of a command file to provide
  890. convenient program break points.  When the "DOT" prompt appears,
  891. interactivecommands such as LIST M in the regular dBASE III dot (".") prompt.
  892. Pressing <RETURN> at the "DOT" prompt will return execution to the calling
  893. program.
  894.  
  895.           * ---DOT.PRG
  896.           DO WHILE .T.
  897.              ACCEPT "DOT " TO command
  898.              IF "" = command
  899.                 EXIT
  900.              ENDIF
  901.              &command
  902.           ENDDO
  903.           RETURN
  904.  dFORMAT will not allow more than one formatPICTURE to be defined.  Page 33 of
  905. the help file (see below) shows 3 being defined, but if this example is entered,
  906. a and b result in the "Undefined format identifier" error message.
  907.       ___________________
  908.      |                   |
  909.      |!   !!             |   "Noname" format defined as "!!"
  910.      |!a  99999          |   "a" format defined as "99999"
  911.      |!b  99/99/99       |   "b" format defined as "99/99/99"
  912.      |                   |
  913.      | <state!  <zip!a   |   Use "Noname" format for state, "a"
  914.      |                   |   format for zip
  915.      | Date >date!b      |   Use "b" format for date
  916.      |___________________|
  917.  
  918.  Even though the error messages are displayed, dFORMAT generates the following
  919. code.  Notice the second and third PICTURE clauses are not completed.
  920.  
  921.      * fmttest.FMT
  922.      * ! !!
  923.      * !a 99999
  924.      * !b 99/99/99
  925.      @ 5,1 GET state PICTURE "!!"
  926.      @ 5,10 GET zip PICTURE        <--- This is not complete.
  927.      @ 7,0 SAY "Date"
  928.      @ 7,6 SAY date PICTURE        <--- This is not complete.
  929.  
  930.  The structure of .DBT files is very simple.  The entire file is handled in
  931. blocks of 512 bytes.  Each block is numbered sequentially 1, 2, 3, etc.
  932.  The first block is the header and can be considered block number zero.  Only
  933. the first four bytes of the header are used.  These first four bytes contain the
  934. number of the next available 512 byte block.  This number is in hex with byte
  935. one containing the least significant portion of the number.  For example, if the
  936. next available block is number 200, the first four bytes of the .DBT file will
  937. contain: C8 00 00 00.  If the next available block is number 4321, the bytes
  938. will look like: E1 10 00 00, and so on.
  939.  
  940.  BLOCK #:     .DBT datafile:
  941.               __________________________
  942.              |                          |
  943.        0     | 05 00 00 00 ...          |
  944.              |__________________________|
  945.              |                          |
  946.        1     | first memo field saved   |
  947.              |__________________________|
  948.              | second memo field saved  |
  949.        2     | (exceeds 512 bytes)      |
  950.              |__________________________|
  951.              |                          |
  952.        3     | still second memo field  |
  953.              |__________________________|
  954.              |                          |
  955.        4     | third memo field saved   |
  956.              |__________________________|
  957.  
  958.        5      next available block (not yet in file)
  959.  
  960.  Each memo field of each record in the .DBF file contains the number of the
  961. block (in ASCII) where the memo field data is located.  If the memo field
  962. contains no data, there is no number in the .DBF file.  When you write to the
  963. memo field, the next available block is used, and its number is stored in ASCII
  964. in the memo field of that record (invisibly behind the word 'memo').
  965.  When data is changed in a memo field, the old contents remain in the .DBT file,
  966. the entire changed contents are rewritten to the next available block, and the
  967. number in the .DBF is changed to reflect the new location.  This leaves the old
  968. block unused with no pointer to it in the .DBF, and explains why .DBT files grow
  969. to such large sizes when edited repeatedly.  When the file is copied from within
  970. dBASE III with USE <filename> and COPY TO <filename>, only the blocks that are
  971. pointed to get copied, thus discarding blocks no longer used and recovering the
  972. disk space.
  973.  If the data written to a memo field uses more than one 512 byte block, the next
  974. available block number is incremented by the number of blocks added.  In other
  975. words, if the next available block is number 15, after 1200 bytes are entered,
  976. the next available block will be 18.
  977.  Each memo field is terminated with two hex 1A bytes.  If 520 characters are
  978. entered into a memo field, the ninth and tenth bytes of the next block will hold
  979. these terminators.  The remaining 502 bytes of this block will be unused.
  980.  This information is valid for versions 1.0 and 1.1, and is subject to change in
  981. future versions.
  982.  
  983.  >>> Recreating a corrupted dBASE III header
  984.  To "recreate" a corrupted dBASE III datafile header, you will need to follow
  985. the two steps listed below.  The second step requires that you run a BASIC
  986. program.
  987.  
  988.  First: Use the CREATE command in dBASE III to construct a new dBASE III
  989. datafile header of the datafile you are attempting to recover. For example,
  990.  
  991.      . CREATE Tempfile
  992.  
  993.      {Now, enter all the field names and descriptors found in
  994.      the old database file.
  995.  
  996.  
  997.  Second: Run the BASIC program listed below.  This program will work with the
  998. IBM PC BASICA.  You can enter this program in dBASE III using MODIFY COMMAND.
  999.  
  1000.  100 'Program.: NEWHEAD.BAS
  1001.  101 'Author..: Luis A. Castro
  1002.  102 'Date....: 12/12/84
  1003.  103 'Notes...: Run the program as follows:
  1004.  
  1005.  130 '
  1006.  150 '    A>BASICA NEWHEAD   (IBM-PC BASIC)
  1007.  160 '
  1008.  200 PRINT "*** ALL INPUT MUST BE IN UPPERCASE AND ***"
  1009.  210 PRINT "*** ALL FIENAMES MUST INCLUDE EXTENSIONS ***"
  1010.  220 PRINT
  1011.  250 INPUT "Enter new structure FILENAME.EXT ",NEWFILE$
  1012.  260 INPUT "Enter old FILENAME.EXT ",OLDFILE$
  1013.  300 '
  1014.  310 'Open the datafiles.
  1015.  320 OPEN "R", #1, NEWFILE$, 32
  1016.  330 FIELD #1,4 AS NEW1$,2 AS NEWLO$,2 AS NEWHI$
  1017.  340 FIELD #1,8 AS DUMMY$,2 AS NEWLEN$,22 AS NEW2$
  1018.  350 OPEN "R", #2, OLDFILE$, 32
  1019.  360 FIELD #2,4 AS OLD1$,2 AS OLDLO$,2 AS OLDHI$
  1020.  400 '
  1021.  410 'Change the record count and save it.
  1022.  415 GET #1,1
  1023.  420 GET #2,1
  1024.  430 PRINT "Number of records ";CVI(OLDLO$)  'Up to 32767 records.
  1025.  440 INPUT "        Change to  ",NEWVAL%
  1026.  450 FLDTOTAL% = (CVI(NEWLEN$) - 34) / 32
  1027.  460 FIELD #2,32 AS OLDFLD$
  1028.  470 LSET OLDFLD$=NEW1$+MKI$(NEWVAL%)+NEWHI$+NEWLEN$+NEW2$
  1029.  480 PUT #2,1
  1030.  500 '
  1031.  510 'Save the new fields.
  1032.  520 FIELD #1,32 AS NEWFLD$
  1033.  540 FOR FLDCOUNT%=1 TO FLDTOTAL%
  1034.  550   GET #1,FLDCOUNT% + 1
  1035.  560   LSET OLDFLD$=NEWFLD$
  1036.  570   PUT #2,FLDCOUNT% + 1
  1037.  580 NEXT FLDCOUNT%
  1038.  600 '
  1039.  610 'Strip off the end-of-file marker and exit.
  1040.  620 CLOSE 2
  1041.  630 OPEN "R", #2, OLDFILE$, 1
  1042.  640 FIELD #2,1 AS ONEBYTE$
  1043.  650 LSET ONEBYTE$=" "
  1044.  660 PUT #2,(FLDTOTAL% + 1) * 32 + 3
  1045.  670 CLOSE 1,2
  1046.  700 SYSTEM
  1047.  
  1048.  >>> dBASE PROGRAM DOCUMENTATION STANDARDS
  1049.  The standards detailed herein have been chosen as a guideline to encourage
  1050. completeness and excellence in documenting your dBASE program files.  They are
  1051. not intended to be looked at as the final word in dBASE file documentation.
  1052.  Make sure that the standards that you set for yourself are general enough to
  1053. apply to all the programs in your system, and detailed enough for you to know
  1054. what you did several months later.  Select a standard that communicates well and
  1055. stick to it.
  1056.  These standards for file documentation are divided into four catagories:  file
  1057. names, feild names, memory variable names, and program documentation.
  1058.  
  1059.  I. File Names
  1060.  DATABASE SYSTEM:  The first two letters identify all files belong- ing to the
  1061. same database system.  In this case, NW identifies all files in the Number/Word
  1062. system.  This facilitates ease of copying or getting directory listings of the
  1063. entire system.  For example:
  1064.  
  1065.      A> COPY B:NW/*.PRG
  1066.      A> DIR NW/*.*
  1067.  
  1068.  SEPARATOR:  A slash (/) or underline (_) is the third character of the file
  1069. name.  It helps to distinguish the database system name from the unique function
  1070. name, and from other system files having the same first two letters.  For
  1071. instance, on a DIR of NW/*.*, the file NWESTERN.TXT will not appear.
  1072.  
  1073.  UNIQUE FUNCTION:  The next five characters describe the unique function of the
  1074. file,  of which the 5th character may be used to describe a different version of
  1075. the same function.  (e.g. NW/DIGIT2.CMD, NW/DIGI3.CMD/,NW/DIGI4.CMD, etc.)
  1076.  
  1077.  EXTENTION:  The default extentions provided by dBASE are used.
  1078.  
  1079.  RESERVED WORDS:  All dBASE command words.
  1080.  
  1081.  CAPITALIZATION:  Capitalize the first letter of all file names.
  1082.  
  1083.  II.  Field Names:
  1084.  Be as discriptive as possible, rather than cryptic.  Use of the colon greatly
  1085. improves readability.
  1086.  
  1087.           Descriptive                  Cryptic
  1088.           -----------                  -------
  1089.           First:name                   Fn
  1090.           Item:amt                     Iamt
  1091.  
  1092.  LOGICAL FIELDS:  Logical fields begin with the letters "Is".
  1093.  
  1094.      Examples :        Is:true           Is:paid
  1095.  
  1096.  RERSERVED WORDS and CAPITALIZATION are the same as for file names.
  1097.  
  1098.  III.  Memory variable names:
  1099.  Basically the same as for field names:
  1100.  
  1101.      1. Be descriptive, not cryptic.
  1102.      2. No dBASE reserved words.
  1103.      3. Start logical memvars with "is".
  1104.  
  1105.  UNIQUE IDENTIFIERS:  The first letter is "m" when the mem var duplicates a file
  1106. name, field name, or a dBASE reserved word. i.e., call your logical memvar
  1107. "mis:true" only if there is a field called "Is:true".
  1108.  When used with RELEASE ALL LIKE, RELEASE ALL EXCEPT, and SAVE ALL LIKE
  1109. housekeeping is a breeze!  For instance, "transient" variables--those that are
  1110. used only within one command file and get released at ther end of that
  1111. file--start with "t:".  In this case, t:name, t:store, and t:is:true would all
  1112. be cleared with the command RELEASE ALL LIKE t:*.  Those mem vars that get SAVEd
  1113. might start with "s:", and are SAVEd with SAVE ALL LIKE s:*.
  1114.  
  1115.  CAPITALIZATION:  Memory variable names are all lowercase letters.
  1116.  
  1117.  RESERVED WORDS:  All dBASE command words.
  1118.  
  1119.  IV.  Program documentation:
  1120.   HEADER:  Example:
  1121.  
  1122.      * Program..: <program name with extention>
  1123.      * Author...: <your name>
  1124.      * Date.....: <date program was written>
  1125.      * Notice...: <Copyright or other notice>
  1126.      * Notes....: <brief description of what program does>
  1127.                   <structure of data files used>
  1128.                   <names of command files called>
  1129.                   <files called from, if part of a system>
  1130.                   <parameters passed>
  1131.                  <other information necessary to run the program>
  1132.                   <optional: trasient memvars, and function status>
  1133.  
  1134.  BODY:  Separate the logical internal modules of the program with a blank line
  1135. or an asterisk (*), and proceed each module with a short description of its
  1136. function.  For example:
  1137.  
  1138.      * Initialize memory variables...
  1139.      STORE " " TO select
  1140.      STORE $(STR(0,81),1,80) TO blank
  1141.      STORE "Y" TO continue
  1142.      *
  1143.      * Open database and locate record...
  1144.      USE Names
  1145.      LOCATE FOR Name = "Jim"
  1146.      DISPLAY
  1147.  
  1148.  Lines between the following commands are "nested" and should be indented three
  1149. spaces:  DO WHILE...ENDDO, IF...ELSE...ENDIF, and DO CASE...ENDCASE.
  1150.  Since the TEXT...ENDTEXT statements will cause all text within them to display
  1151. any indentation as leading spaces in the output, when using them, indent only
  1152. the way you want the output to appear.
  1153.  
  1154.  CAPITALIZATION:  All dBASE command words.
  1155.  
  1156. FOOTER:  Example:
  1157.  
  1158.      * EOF <program name>
  1159.  
  1160.  This program simulates the JOIN command.  This is a "simple" join; that is, the
  1161. JOINing criteria is the key of each file and there are no duplicate keys.  This
  1162. type of join executes very quickly, since the SET RELATION TO &key_expr searches
  1163. for the matching record via the index and not through sequential searches in the
  1164. database file.  The program appends 'firstfile' to 'joinfile,' and rewinds
  1165. 'joinfile.'  It then adds the 'secondfile' fields to 'joinfile' for records that
  1166. match the key field.
  1167.  
  1168.  * Program.: S-JOIN.PRG (III)
  1169.  * Author..: Luis A. Castro, modified by David McLoughlin
  1170.  * Date ...: 01/11/83, 01/17/84, 06/24/84, 11/16/84
  1171.  *
  1172.  SET TALK OFF
  1173.  *
  1174.  * ---The parameters may be initialized with STORE statements
  1175.  * ---or entered from the keyboard with ACCEPT statements
  1176.  * ---(that is, the STORE verbs can be changed to ACCEPT verbs).
  1177.  firstfile = "FIRST"
  1178.  secondfile = "SECOND"
  1179.  joinfile = "JOIN-TO"
  1180.  key_expr = "Lastname+Firstname"
  1181.  *
  1182.  * ---Initialize macro to REPLACE to joinfile from secondfile.
  1183.  * ---Assumes only Name and Amount fields need replacing.
  1184.  mreplace = "Name WITH B->Name, Amount WITH B->Amount"
  1185.  *
  1186.  * ---Joinfile has all the desired fields to be JOINed.
  1187.  * ---It is created before the program is executed,
  1188.  * ---and contains no records.
  1189.  SELECT A
  1190.  USE &joinfile
  1191.  APPEND FROM &firstfile
  1192.  GO TOP
  1193.  SELECT B
  1194.  * ---Assumes the second file and index file have the same name.
  1195.  USE &secondfile INDEX &secondfile
  1196.  SELECT A
  1197.  SET RELATION TO &key_expr INTO B
  1198.  DO WHILE .NOT. EOF()
  1199.     SELECT B
  1200.     IF .NOT. EOF()
  1201.        * ---A matching record.
  1202.        SELECT A
  1203.        * ---REPLACE to joinfile from secondfile.
  1204.        REPLACE &mreplace
  1205.     ENDIF
  1206.     SELECT A
  1207.     SKIP
  1208.  ENDDO
  1209.  CLEAR ALL
  1210.  SET TALK ON
  1211.  RETURN
  1212.  * EOF: S-JOIN.PRG
  1213.  
  1214.  dBASE III  L I M I T A T I O N S
  1215.  
  1216.  >>> @...SAY has row and column limits of 255
  1217.  The manual for dBASE III version 1.00 does not specify that the row and column
  1218. coordinates of @...SAY may not exceed 255.
  1219.  
  1220.  
  1221.  >>> CHR() limit of 255
  1222.  Attempting to access a CHR(n) where 'n' is greater than 255 will result in the
  1223. undocumented error message:
  1224.  
  1225.      *** Execution error on CHR():  Out of range
  1226.  
  1227.  >>> Dates greater than the 20th century
  1228.  It is possible to declare a century other than the 20th for date fields.  For
  1229. example:
  1230.  
  1231.      REPLACE <Fieldname> WITH CTOD("12/14/2010")
  1232.  
  1233.  will properly replace the century in the file, and it can be retrieved with ?
  1234. YEAR(Fieldname).  However, the use of any commands which employ full-screen
  1235. editing will change the date to the default century (20th), whether or not the
  1236. date field is changed.
  1237.  
  1238.  >>> REPORT FORM using the HEADING option
  1239.  Although not documented anywhere in the manual, when the HEADING option of the
  1240. REPORT FORM is used, the heading will wrap at 40 columns.
  1241.  
  1242.  >>> STR() parameter limits
  1243.  (Corrected in the 2nd edition of the manual.)
  1244.  If no length is specified in the STR() function, it defaults to a length of 10.
  1245.  This is not mentioned in the function section on page 5-32 of the version 1.0
  1246. manual.  The STR() parameter limits for dBASE III are 19 for length and 15 for
  1247. decimals.
  1248.  
  1249.  >>> MACRO (&) Function
  1250.  
  1251.  The macro (&) function  will not expand properly if it is followed by a space
  1252. and parentheses.  For example:
  1253.  
  1254.       STORE 'LIST FOR' TO x
  1255.       STORE 10 TO memvar
  1256.       &x Field1 = memvar
  1257.  
  1258.  will execute properly, but,
  1259.  
  1260.       &x (Field1 - memvar) * memvar = 0
  1261.  
  1262.  will return the "*** Unrecognized command verb" error message. This problem can
  1263. be avoided by terminating the macro-substituted memory variable with a period.
  1264. For example,
  1265.  
  1266.       &x. (Field1 - memvar) * memvar = 0
  1267.  
  1268.  will work.  It is always a good idea to terminate a macro with a period.
  1269.  
  1270.  
  1271.  >>> Memo Fields
  1272.  
  1273.  A problem displaying memo fields has been found in dBASE III by one of our
  1274. users.  The problem occurs when you try to list or print a memo field preceded
  1275. by a field whose length will force the first line of the memo field to wrap
  1276. around one or more times.
  1277.  
  1278.  Assume a file structure consisting of two fields:
  1279.  
  1280.  
  1281.       Structure for database: Example.DBF
  1282.       Field  Field Name  Type       Width    Dec
  1283.           1  Field1      Character    100
  1284.           2  Field2      Character     70
  1285.           3  Comments    Memo          10
  1286.       ** Total **                     181
  1287.  
  1288.  These display commands
  1289.  
  1290.       ? SPACE( 1 ), Comments
  1291.       ? Field1, Comments
  1292.       ? Field2, Comments
  1293.       ? Field1, Field2, Comments
  1294.  
  1295.  will all produce different results.
  1296.  
  1297.  If the total length of the fields preceding the memo field is 29 or above, the
  1298. first line of the memo field will wrap around.  The entire memo field will then
  1299. be displayed in double space. Futhermore, if the total length of the fields
  1300. preceding the memo field is long enough to force the first line of the memo
  1301. field to be displayed starting on the second line of the display, then the
  1302. entire memo field will be displayed in triple space.
  1303.  
  1304.  
  1305.  
  1306.  >>> Memo fields, displayed from an unSELECTed area
  1307.  
  1308.  An attempt to display a memo field from an unSELECTed work area will produce
  1309. the error message "Unrecognized phrase/keyword in command". For example:
  1310.  
  1311.      SELECT A
  1312.      USE First
  1313.      SELECT B
  1314.      * ---The following database file has the character
  1315.      * ---field 'Name' and a memo field 'Notes'.
  1316.      USE Second
  1317.      SELECT A
  1318.      * ---This works correctly.
  1319.      ? Second->Name
  1320.      *
  1321.      * ---The following line returns the error message,
  1322.      * ---"Unrecognized phrase/keyword in command".
  1323.      ? Second->Notes
  1324.      *
  1325.      * ---The following line returns,
  1326.      * ---"No database in USE, enter filename:"
  1327.      LIST Second->Notes
  1328.  
  1329.  
  1330.  >>> MODIFY COMMAND
  1331.  
  1332.  When using the Ctrl-K-R in the dBASE III word processor, there is a limit of
  1333. fifteen characters to the name of the file being imported.  If the name of the
  1334. file, including drive designator and path, is sixteen characters or longer,
  1335. problems will occur.  The computer may freeze with the message "File does not
  1336. exist (Hit SPACE)" being displayed; or the error message "*** STACK OVERFLOW
  1337. ***" appears and the user is returned to PC/MS-DOS.  For example, the filenames:
  1338.  
  1339.          B:\A\Data10.TXT
  1340.          B:\Datapath\One
  1341.  
  1342.  are acceptable, while
  1343.  
  1344.          B:\A\Data101.TXT <-- "File does not exist (Hit SPACE)"
  1345.          B:\Datapath\File <-- "*** STACK OVERFLOW ***"
  1346.  
  1347.  are not.  In the Developer's Release, MODIFY COMMAND will support filenames
  1348. including paths exceeding sixteen characters.
  1349.  
  1350.  
  1351.  >>> MODIFY STRUCTURE
  1352.  
  1353.  It has been reported that MODIFY STRUCTURE will occasionally write a 00H in the
  1354. delete marker position of a group of records in a database file, causing those
  1355. records to be shifted one character to the right on LIST and DISPLAY. The
  1356. records will appear normal with other commands such as EDIT and REPORT FORM.
  1357.  
  1358.  To date, this problem has only been reported on the IBM PC AT. If it occurs,
  1359. DELETE and RECALL the offending records to restore the delete marker to its
  1360. normal state, a 20H.  (For more information on data record structures, see page
  1361. D3-15.)  For example:
  1362.  
  1363.       . USE Bad_file
  1364.       . LIST
  1365.  
  1366.       Record#  NAME       CODE  PHONE
  1367.             1  Joe        AAA   (111)111-1111
  1368.             2   Mary       BBB   (222)222-2222
  1369.             3   Tom        CCC   (333)333-3333
  1370.             4   Alice      DDD   (444)444-4444
  1371.             5  Betty      EEE   (555)555-5555
  1372.  
  1373.       . GOTO 2
  1374.       . DELETE NEXT 3
  1375.             3 records deleted
  1376.       . GOTO 2
  1377.       . RECALL NEXT 3
  1378.             3 records recalled
  1379.       . LIST
  1380.  
  1381.       Record#  NAME       CODE  PHONE
  1382.             1  Joe        AAA   (111)111-1111
  1383.             2  Mary       BBB   (222)222-2222
  1384.             3  Tom        CCC   (333)333-3333
  1385.             4  Alice      DDD   (444)444-4444
  1386.             5  Betty      EEE   (555)555-5555
  1387.  
  1388.  
  1389.  >>> Numeric Accuracy Inconsistencies
  1390.  
  1391.  There are some inconsistencies with the manner in which dBASE III handles
  1392. numeric operations, especially comparisons.  What follows are two examples that
  1393. return unexpected results.
  1394.  
  1395.   EXAMPLE 1:
  1396.  
  1397.       . ? 4.1 - 2.1
  1398.        2.0
  1399.       . ? INT(4.1 - 2.1) = 2
  1400.       .F.
  1401.       . ? INT(4.1 - 2.1)
  1402.          1
  1403.  
  1404.   EXAMPLE 2:
  1405.  
  1406.       . ? SQRT(100)
  1407.            10.00
  1408.       . ? SQRT(100) = 10
  1409.       .F.
  1410.       . ? INT(SQRT(100)) = 10
  1411.       .F.
  1412.       . ? INT(SQRT(100))
  1413.                9
  1414.  
  1415.  The only reliable way to compare two numbers in dBASE III is to use the STR()
  1416. function.  For example:
  1417.  
  1418.       . ? STR(SQRT(100),10,2) = STR(10,10,2)
  1419.       .T.
  1420.  
  1421.  
  1422.  >>> PARAMETERS
  1423.  
  1424.  Misspelling the command PARAMETERS or omitting the command in a procedure file
  1425. will produce an irrelevant error message.  The error will usually be a syntax
  1426. error ona command line that looks like a RETURN with a right arrow where the "R"
  1427. should be.  This error will also occur if an incorrect number of values are
  1428. passed in the DO <filename> WITH <parameter list> command.  For example:
  1429.  
  1430.       * Program..: Areacalc.PRG
  1431.          PARAMATERS length,width,area
  1432.       area = length * width
  1433.       RETURN
  1434.       * EOP: Areacalc.PRG
  1435.  
  1436.       * The following command is entered from the dot prompt.
  1437.       DO Areacalc WITH 6,4,0
  1438.  
  1439.       Syntax Error
  1440.        ?
  1441.  
  1442.  A space following a memory variable in a PARAMETERS statement will return the
  1443. "Unrecognized phrase/keyword in command" error message.  The following command
  1444. sequence demonstrates this anomaly.
  1445.  
  1446.  * Test.PRG
  1447.           PARAMETERS name
  1448.           name = "Steve" ^-------------there is a blank
  1449.           RETURN                       space after "name".
  1450.  
  1451.           . mvar = "John"
  1452.           . DO test WITH mvar
  1453.           Unrecognized phrase/keyword in command
  1454.                      ?
  1455.           PARAMETERS name
  1456.  
  1457.  
  1458.  >>> PROCEDURE with TI Professional
  1459.  
  1460.  With a procedure file open, attempting to DO any command file will result ina
  1461. "*** Syntax error ***."  For example, the command file below will produce the
  1462. error.
  1463.  
  1464.       SET PROCEDURE TO Test1
  1465.       DO Routine  <------------------ Routine is a procedure
  1466.       DO Nonproc  <-----------!       in Test1.
  1467.       RETURN                  !
  1468.                               !------ This is a separate
  1469.                                       command file.
  1470.  
  1471.   DO Routine will execute; however, DO Nonproc will produce the error message.
  1472. This problem has been reported on the TI PRO version of dBASE only.  This will
  1473. not produce an error on the IBM PC version.
  1474.  
  1475.  
  1476.  
  1477.  >>> COPY [STRUCTURE] TO <filename> with SET SAFETY
  1478.  
  1479.  The COPY [STRUCTURE] TO <filename> command ignores the status of SET SAFETY if
  1480. it is issued in a command file.  It will overwrite the target database file
  1481. without warning.  There are two work-arounds for this problem.  The first
  1482. work-around is to use the COPY FILE command instead.  You will have to CLOSE the
  1483. source database before this command can be used.  The other work-around is to
  1484. use the FILE() function to check for the existence of the target file before
  1485. issuing the COPY TO command.  For example:
  1486.  
  1487.      overwrite = .F.
  1488.      IF FILE( "Temp.DBF" )
  1489.          @ 10,0 SAY "File already exists, overwrite it?  (Y/N)";
  1490.          GET overwrite
  1491.          READ
  1492.      ELSE
  1493.          overwrite = .T.
  1494.      ENDIF
  1495.      IF overwrite
  1496.          COPY TO Temp
  1497.      ENDIF
  1498.  
  1499.  
  1500.  >>> COPY TO <filename> DELIMITED
  1501.  
  1502.  If a database file structure contains a large number of character or numeric
  1503. fields with a length of one, the COPY TO <filename> DELIMITED command will
  1504. produce unreliable results.  For example, a file with 29 one-character fields
  1505. will produce a text file with the following record:
  1506.  
  1507.  1,"A","A","A",1,1,"A","A","A","A","A",1,1,1,1,1,1/,"A","A","A",",",",,,",","
  1508.  
  1509.  The last fields in the record have been garbled.
  1510.  
  1511.  
  1512.  >>> COPY TO <filename> DELIMITED WITH without delimiter
  1513.  
  1514.  Using COPY TO <filename> DELIMITED WITH without a delimiter is not trapped as
  1515. an error and will cause one of two problems: (1) if there is a space after the
  1516. WITH, the error "Unrecognized phrase/keyword in command" is displayed; (2) if
  1517. there is no space, the file is copied but the target file will contain all blank
  1518. records.
  1519.  
  1520.  This problem was discovered in an attempt to build a comma separated file in
  1521. which the character strings were not enclosed in delimiters.  Currently, the
  1522. COPY command does not have this capability.  You can, however, create a comma
  1523. separated file in which the character strings are delimited with a blank.  The
  1524. syntax is:
  1525.  
  1526.            COPY TO <filename> DELIMITED WITH BLANK
  1527.  
  1528.  
  1529.  >>> COPY TO <filename> SDF
  1530.  If the database file being copied has a MEMO field, the data in the fields
  1531. following the MEMO field will either not be copied or will be copied
  1532. incorrectly.  To work around this problem, use the FIELDS phrase in the COPY
  1533. command.  For example:
  1534.  
  1535.        COPY TO <filename> FIELDS <field list> SDF
  1536.  
  1537.  
  1538.  >>> CREATE <filename>
  1539.  
  1540.  (1) In dBASE III, a legitimate file name may contain up to eight characters
  1541. consisting of an initial letter, and any combination of letters, numbers, and
  1542. underscores.  However, special characters ($,#,-,@,+,etc.) in the name will
  1543. cause an error message if an <Alias> -> <Fieldname> is used.  For example:
  1544.  
  1545.       USE Names
  1546.       SELECT 2
  1547.       USE Test-it
  1548.       SELECT Names
  1549.       ? Test-it -> Fieldname
  1550.       Variable not found
  1551.              ?
  1552.       ? Test-it -> Fieldname
  1553.  
  1554.  (2) When creating a database file, if <RETURN> is pressed in the first field of
  1555. the screen and editing is then resumed by pressing any key other than <RETURN>,
  1556. the structure of the file saved will be corrupted.  LISTing the STRUCTURE may
  1557. lock the machine.
  1558.  
  1559.  >>> CREATE and alias
  1560.  
  1561.  After you CREATE a file, you must USE it again in order to establish the file
  1562. name as the default alias name.  Otherwise, the file name will have no alias
  1563. name assigned to it.  For example:
  1564.  
  1565.       CREATE File_one
  1566.       * ---Enter file structure.
  1567.       * ---Add a few records.
  1568.       DISPLAY STATUS
  1569.       * ---No alias name appears.
  1570.       SELECT 2
  1571.       USE New_file
  1572.       SELECT File_one
  1573.       * ---Gives "Alias not found" message.
  1574.  
  1575.  
  1576.  >>> DISPLAY OFF
  1577.  
  1578.  When using the command DISPLAY OFF in conjunction with TO PRINT and no
  1579. specified scope in a command file, the DISPLAY will have an extra line-feed
  1580. between each line.  For example:
  1581.  
  1582.       SET HEADING OFF
  1583.       DO WHILE .NOT. EOF()
  1584.          DISPLAY OFF <Field1>, <Field2> TO PRINT
  1585.          SKIP
  1586.       ENDDO
  1587.  
  1588.  will yield:
  1589.  
  1590.   <value1> <value2>
  1591.                              <----------- extra line-feeds
  1592.   <value1> <value2>            |
  1593.                      <---------
  1594.   <value1> <value2>
  1595.  
  1596.  
  1597.  >>> DO with both command and procedure files
  1598.  
  1599.  Executing a command file with the same name as a procedure in a procedure file
  1600. that has been opened and closed causes return pointers to be lost.  For example,
  1601. if a file has a nested DO WHILE, RETURNing from the subprogram will cause the
  1602. controlling DO WHILE loop to terminate abnormally.  The program below
  1603. demonstrates this problem.
  1604.  
  1605.       *--- Test.PRG
  1606.       DO WHILE .T.
  1607.         SET PROCEDURE TO Testa
  1608.         DO Test1         <-- From Testa.PRG.
  1609.         CLOSE PROCEDURE
  1610.         DO Test1         <-- Separate command file
  1611.       ENDDO                       <-- will terminate although no
  1612.                               EXIT or RETURN has been executed.
  1613.  
  1614.  This problem has been corrected in the Developer's Release of dBASE III.
  1615.  
  1616.  
  1617.  >>> DO WHILE with semicolon
  1618.  
  1619.  When a DO WHILE conditional statement is continued to a second line with a
  1620. semicolon, dBASE III tries to execute this second line the second time through
  1621. the loop.  When the ENDDO is encountered and the condition evaluates as true,
  1622. program flow proceeds to this second line, resulting in the error message, "***
  1623. Unrecognized command verb."  For example:
  1624.  
  1625.       * ---This program will give an error message
  1626.       * ---when "Y" is entered at the WAIT prompt.
  1627.       answer = 'Y'
  1628.       number = 1
  1629.       DO WHILE number < 10;
  1630.          .AND. answer = 'Y'
  1631.          ? number
  1632.          WAIT '"Y" to continue ' TO answer
  1633.          number = number + 1
  1634.       ENDDO
  1635.  
  1636.  If "Y" is entered at the WAIT prompt, dBASE III tries to execute ".AND. answer
  1637. = 'Y'."  However, if the semicolon is deleted and the line is allowed to wrap at
  1638. column 67 in MODIFY COMMAND, execution flows correctly.
  1639.  
  1640.  
  1641.  >>> DO WHILE with RETURN
  1642.  
  1643.  A RETURN statement inside a DO WHILE...ENDDO construction will not close the DO
  1644. WHILE <condition> in the program as it does in dBASE II.  Therefore, the
  1645. <condition> will continue to be evaluated.  For example:
  1646.  
  1647.       * A.PRG
  1648.       expA = "1"
  1649.       DO WHILE expA = "1"
  1650.          ? "Hi!"
  1651.          DO B     --------------->  * B.PRG
  1652.       ENDDO                         expB = "2"
  1653.       * EOF: A.PRG                  DO WHILE expB = "2"
  1654.                                        ? "How are you?"
  1655.                                        expA = "X"
  1656.                                        RETURN
  1657.                                     ENDDO
  1658.                                     * EOF: B.PRG
  1659.  
  1660.  Executing A.PRG will cause an infinite loop.  It appears dBASE III continues to
  1661. test the condition of expB.  In order to work around this, B.PRG should be
  1662. written as follows:
  1663.  
  1664.       * B.PRG (revised).
  1665.       expB = "2"
  1666.       DO WHILE expB = "2"
  1667.          ? "How are you?"
  1668.          expA = "X"
  1669.          EXIT             <----- Notice, the EXIT here,
  1670.       ENDDO
  1671.       RETURN              <----- and the RETURN here.
  1672.       * EOF: B.PRG
  1673.  
  1674.  
  1675.  >>> DO WHILE with an extra ENDDO
  1676.  
  1677.  If an extra ENDDO is added to a command file, an infinite loop will result. For
  1678. example, the following program will execute until Esc is pressed:
  1679.  
  1680.       number = 0
  1681.       DO WHILE number < 10
  1682.          @ 10,10 SAY "Now at loop " + STR(number,2)
  1683.          STORE number + 1 TO number
  1684.       ENDDO
  1685.       ENDDO           <--- This ENDDO has no matching DO WHILE.
  1686.       RETURN
  1687.  
  1688.  We recommend you use some method of indentation for the control structures: DO
  1689. CASE...ENDCASE, DO WHILE...ENDDO, and IF...ENDIF to avoid this problem. This
  1690. practice will make command files more readable, and will allow for quick visual
  1691. checking for accuracy of nested control structures.  In our example, two
  1692. consecutive ENDDO statements with the same left margin is a definite indication
  1693. that something is wrong.
  1694.  
  1695.  
  1696.  
  1697.  >>> @...GET
  1698.  
  1699.  Any command that allows editing of a record will only operate in the SELECTed
  1700. work area.  However, attempting an @...SAY...GET using an ALIAS or SELECT to
  1701. access another work area in a format (.FMT) file will not produce an error
  1702. message. Instead, the entire line is suppressed, including the SAY statement.
  1703. The Developer's Release of dBASE III will return the "Variable not found" error
  1704. message if any attempt is made to GET a field from another work area.  In
  1705. versions 1.0 and 1.1 of dBASE III, the command:
  1706.  
  1707.       @ 10,4 SAY "Testing " GET B->Test
  1708.  
  1709.  in a format file will not display anything on the screen. Issuing this command
  1710. from the dot prompt or in a command file will return "Variable not found."  An
  1711. alias name is acceptable in a SAY statement, even in a format file.
  1712.  
  1713.       @ 10,4 SAY "Testing " + B->Test
  1714.  
  1715.  will display properly.
  1716.  
  1717.  Notice that in the first example neither the SAY nor the GET pertaining to the
  1718. second work area are displayed.
  1719.  
  1720.  
  1721.   >>> @...SAY...GET
  1722.  
  1723.  (1) When entering numbers to the right of the decimal place of numeric fields,
  1724. typing the period will sometimes cause the cursor to jump back to the beginning
  1725. of the field.  This problem manifests itself only when using a database file
  1726. with one or more index files.  The problem will also occur using APPEND, BROWSE,
  1727. CHANGE, and EDIT.
  1728.  
  1729.  There are numerous work-arounds for this anomaly, but not all of them work all
  1730. of the time.  First, try reducing the number of buffers used in Config.sys to
  1731. between 12 and 15.  If this doesn't solve the problem and you are using an
  1732. Autoexec.bat file, try removing the batch file from your boot disk.  Finally, if
  1733. there is a DEVICE=ANSI.SYS entry in Config.sys, try removing the entry.  Note:
  1734. You will need to reboot the machine in order for any of these changes to take
  1735. effect.
  1736.  
  1737.  (2) Skipping through @...GETs with the PgDn key will yield different results in
  1738. dBASE III as compared to dBASE II.  For example:
  1739.  
  1740.       * ---Getting date values.
  1741.       STORE "        " TO a,b,c
  1742.       @ x,y GET a PICTURE "99/99/99"
  1743.       @ x,y GET b PICTURE "99/99/99"
  1744.       @ x,y GET c PICTURE "99/99/99"
  1745.       READ
  1746.  
  1747.  Entering "01/01/84" for the first GET field (memvar "a") then pressing the PgDn
  1748. key for the second GET field (memvar "b") will give the following results:
  1749.  
  1750.       in dBASE II:   A = "01/01/84"
  1751.                      B = "  /  /  "
  1752.                      C = "  /  /  "
  1753.  
  1754.       in dBASE III:  A = "01/01/84"
  1755.                      B = "  /  /  "
  1756.                      C = "        "   <--- This one is blank.
  1757.  
  1758.  (3) If text is printed to the screen with @...SAY, and then an @...SAY...GET is
  1759. printed to the same line without erasing it first, characters from the previous
  1760. text will appear between the SAY and the GET.  For example:
  1761.  
  1762.       STORE '123' TO mem
  1763.       @ 10,0 SAY 'XXXXXXXXXXXX'
  1764.       @ 10,0 SAY 'A' GET mem
  1765.  
  1766.  displays:
  1767.  
  1768.       AX123XXXXXXX
  1769.        ---------------- This should not be displayed.
  1770.  
  1771.  (4) If you attempt to do a GET at a location greater than or equal to 80, the
  1772. error message "SAY/GET position is off the screen" will be displayed. However,
  1773. if you issue an @...SAY...GET that places the first character of the GET field
  1774. in column 80, the machine will lock, requiring a warm boot.  For example:
  1775.  
  1776.       STORE 'TEST' TO test
  1777.       @ 10,78 SAY 'x' GET test
  1778.  
  1779.  Note that this problem occurs only in this one instance.  If the column
  1780. coordinate in the above example is changed to 79, no error message is displayed
  1781. and the GET wraps around to the next line on the screen.
  1782.  
  1783.  
  1784.  >>> @...SAY...PICTURE
  1785.  Using the template symbols "$", ",", and "9" in an @...SAY PICTURE clause may
  1786. cause more than one dollar sign to be displayed on the screen.  Specifically, if
  1787. the value being displayed does not fill positions in the display string
  1788. preceding the comma position, a dollar sign will be displayed in place of the
  1789. comma.  For example:
  1790.  
  1791.       mem = 123456
  1792.       @ 10,0 SAY mem PICTURE "$999,999,999"
  1793.       @ 11,0 SAY mem PICTURE "$999,999,999,999"
  1794.  
  1795.  will output:
  1796.  
  1797.       $   $123,456
  1798.       $   $   $123,456
  1799.  
  1800.  The PICTURE template, ($), is intended to replace leading zeros in a numeric
  1801. display with dollar signs.  This means that  dollar signs should always display
  1802. in a fixed position format.  To display a fixed position dollar sign leading a
  1803. numeric expression with embedded commas, use two @...SAY commands, one to
  1804. display the dollar sign and the other to display the numeric variable with the
  1805. embedded commas.  For example,
  1806.  
  1807.       mem = 1234.56
  1808.       @ 10,10 SAY "$"
  1809.       @ ROW(),COL() + 1 SAY mem PICTURE "99,999.99"
  1810.  
  1811.  If you wish a leading dollar sign that is floating for numeric variables with
  1812. embedded commas, a feature not directly supported by dBASE III, use the
  1813. following command file to format the numeric variables.
  1814.  
  1815.       * Commas.PRG
  1816.       PARAMETERS mem
  1817.       mvar = SUBSTR( STR( mem, 9, 2 ), 1, 3 ) + ",";
  1818.            + SUBSTR(     STR( mem, 9, 2 ), 4, 3 );
  1819.            + SUBSTR( STR( mem, 9, 2 ), 7, 3 )
  1820.       cntr = 1
  1821.       DO WHILE SUBSTR( mvar, cntr, 1 ) $ ", "
  1822.          cntr = cntr + 1
  1823.       ENDDO
  1824.       cnum = SPACE( cntr - 1 ) + "$" + SUBSTR( mvar, cntr )
  1825.       @ 10,0 SAY cnum
  1826.       * EOP Commas.PRG
  1827.  
  1828.       STORE 1234.56 TO x
  1829.       DO Commas WITH x
  1830.  
  1831.  outputs:
  1832.  
  1833.       $1,234.56
  1834.  
  1835.  This formula will work with numbers as large as $999,999.99. Larger numbers
  1836. require that the length argument of the STR() function and the length and
  1837. starting point arguments of the SUBSTR() function be changed to accommodate the
  1838. larger number. For numbers as large as $999,999,999.99 the second line of the
  1839. preceding program should be changed to:
  1840.  
  1841.       mvar = SUBSTR( STR( mem, 12, 2 ), 1, 3 ) + ",";
  1842.            + SUBSTR( STR( mem, 12, 2 ), 4, 3 ) + "," ;
  1843.            + SUBSTR( STR( mem, 12, 2 ), 7, 3 ) +;
  1844.              SUBSTR( STR( mem, 12, 2 ), 10, 2 )
  1845.  
  1846.  This problem persists in the Developer's Release including both the PICTURE
  1847. clause and the TRANSFORM() function.  The work-arounds are a little bit easier
  1848. given some new functions including TRANSFORM() itself.  To display a numeric
  1849. expression with a leading dollar sign in fixed position and embedded commas
  1850. concatenate a dollar sign to the result of the TRANSFORM() of the numeric
  1851. expression.  For example,
  1852.  
  1853.       mem = 1234.56
  1854.       @ 10,10 SAY "$" + TRANSFORM( mem, "99,999.99" )
  1855.  
  1856.  To display a floating dollar sign leading a numeric expression with embedded
  1857. commas, insert the dollar sign into the result of the TRANSFORM() function on
  1858. the numeric expression.  For example,
  1859.  
  1860.       mem = 1234.56
  1861.       @ 10,10 SAY SPACE(10-LEN(LTRIM(TRANSFORM(mem,"99,999.99"))));
  1862.                          ^--------- Length of the TRANSFORM() picture.
  1863.                   + "$" + TRANSFORM(mem,"99,999.99")
  1864.  
  1865.  It is important to note that the first element in the SPACE() function argument
  1866. must be the length of the TRANSFORM() picture.  If, for example, the picture is
  1867. "999", then the element is three.
  1868.  
  1869.  
  1870.  >>> @...SAY...PICTURE
  1871.  
  1872.  (1) The C and X functions documented in the manual reference to the @...SAY
  1873. command will always display positive numbers as credits (CR) and negative
  1874. numbers as debits (DB).  Use the following program segment if you need them to
  1875. display in the reverse order (that is, positive numbers as debits (DB) and
  1876. negative numbers as credits (CR)):
  1877.  
  1878.       DO CASE
  1879.          CASE number > 0
  1880.             @ row,col SAY STR(number,17,2) + "DB"
  1881.          CASE number < 0
  1882.             @ row,col SAY STR(-number,17,2) + "CR"
  1883.          OTHERWISE
  1884.             @ row,col SAY STR(number,17,2)
  1885.       ENDCASE
  1886.  
  1887.  (2) The A and ! PICTURE clause functions are mutually exclusive. That is, you
  1888. cannot combine the two to make a new function that will limit data input to
  1889. alphabetic characters and force the letters to uppercase. If A and ! are used
  1890. together, only the second function will be in effect.  For example:
  1891.  
  1892.       PICTURE "@A!"  is equivalent to   PICTURE "@!"
  1893.       PICTURE "@!A"  is equivalent to   PICTURE "@A"
  1894.  
  1895.  (3) There is no PICTURE clause that applies to a logical vaiable in an @...GET
  1896. command.  However, if you attempt to use a PICTURE clause on a logical field or
  1897. memory variable, dBASE III will not trap it as an error.  When the READ is
  1898. executed, dBASE III will not pause for user input, and the value of the field or
  1899. variable will not be changed.
  1900.  
  1901.  One possible occurrence of this is when a memory variable is declared PUBLIC
  1902. but is not initialized before an @...GET command. (dBASE III will automatically
  1903. initialize a PUBLIC memory variable to a logical .F.)  If the variable was not
  1904. intended to be a logical variable, the above symptoms will manifest themselves.
  1905. You may want to use the SPACE() function to initialize character variables and
  1906. zero to initialize numeric variables.
  1907.  
  1908.  (4) The zero-suppress function, @Z, will not suppress the decimal point when it
  1909. is used with a non-integer value of zero.  To work around this display problem,
  1910. use the following command sequence instead of the @Z function.
  1911.  
  1912.       IF STR( number, 5, 2 ) <> " 0.00"
  1913.          @ 10,0 SAY number
  1914. e      ENDIF
  1915.  
  1916.  
  1917.  >>> Addition
  1918.  
  1919.  Adding 50 or more numbers together in a single command line will lock the
  1920. computer, requiring a cold boot.  For example, the command ? 1+1+1...+N, where N
  1921. is the 50th number, will produce the correct answer, then freeze the computer.
  1922.  
  1923.