home *** CD-ROM | disk | FTP | other *** search
/ Shareware Overload / ShartewareOverload.cdr / database / db3tips2.zip / ATDB3NTS.TXT next >
Text File  |  1986-07-01  |  68KB  |  1,933 lines

  1.               Ashton-Tate dBASE III Reference Notes
  2.  
  3.      These dBASE III Reference Notes were obtained from the Ashton-Tate
  4. Support Library on CompuServe (GO ASHTON).  
  5.  
  6.                                                Steve Mullen [71676,124]
  7.  
  8.  
  9.                              Menu 1
  10. >>> @...GET...RANGE
  11.  
  12.      RANGE is used in conjunction with @...GET to specify an acceptable
  13. continuous set of input values to date or numeric fields.  The RANGE is
  14. initialized by specifying lower and upper bounds (inclusive) which may
  15. be literal values, memory variables, or expressions.  For example:
  16.  
  17. 1) Literal values:
  18.    @ 10,10 GETvar1  RANGE 1,9
  19.    @ 11,10 GET mdate RANGE CTOD('12/12/84'),CTOD('12/12/85')
  20. 2) Memory variables:
  21.    STORE 1 TO low
  22.    STORE 9 TO high
  23.    @ 10,10 GET var1 RANGE low,high
  24.    STORE CTOD('12/12/84') TO low_date
  25.    STORE CTOD('12/12/85') TO high_date
  26.    @ 10,10 GET mdate RANGE low_date,high_date
  27. 3) Expressions:
  28.    @ 10,10 GET var1  RANGE low+365,high+(365*10)
  29.    @ 11,10 GET mdate RANGE DATE(),high_date+120
  30.  
  31. Entries outside of the defined range will generate an error message and
  32. input will be prompted until a valid entry is made.
  33.  
  34.  
  35. >>> @...GET and READ
  36.  
  37.      (1) If an attempt is made to @...GET memvar PICTURE "999.99" and
  38. the memory variable is not initialized with the number of decimal
  39. places specified in the PICTURE clause, the GET display will not show
  40. the decimal digits for input.  Entering a decimal point will exit the
  41. GET.  For example:
  42.  
  43. * ---Set up numeric input.
  44. num = 0
  45. @ 10,10 SAY "Enter number " GET num PICTURE "999.99"
  46. READ
  47. *
  48. * ---After entering a decimal point during the READ,
  49. * ---the GET will display the following:
  50.  
  51.      Enter number :  0.  :
  52.  
  53. To properly input numeric memory variables with decimal digits using
  54. @...GET...PICTURE, initialize the memory variable with the number of
  55. decimal digits used in the PICTURE clause.  For example:
  56.  
  57. * ---The following command line assigns num with
  58. * ---the same number of decimal digits as found
  59. * ---in the PICTURE clause.
  60. num = 0.00
  61. @ 10,10 SAY "Enter number " GET num PICTURE "999.99"
  62. READ
  63.  
  64. (2) When using @...GET and READ cetain keys will terminate the READ.
  65. The following table shows which keys do so and where in the pending
  66. GETs the key will terminate the READ.
  67.  
  68. Key:        The READ will terminate at:
  69. ----------- ---------------------------
  70. Backspace    First character of first GET
  71. Left arrow   First character of first GET
  72. Right arrow  Last character of last GET
  73. Up arrow     First GET
  74. Down arrow   Last GET
  75. Esc          Anywhere
  76. F1           Anywhere
  77. Ctrl-[       Anywhere
  78. Ctrl-Q       Anywhere
  79. Ctrl-W       Anywhere
  80. Ctrl-Home    Anywhere
  81. Ctrl-End     Anywhere
  82. PgUp         Anywhere
  83. PgDn         Anywhere
  84. Ctrl-PgUp    Anywhere
  85. Ctrl-PgDn    Anywhere
  86. Alt 0-9      Anywhere
  87.  
  88.  
  89. >>> @...GET...PICTURE
  90.  
  91. Assuming a memvar is initialized with zero (that is, memvar = 0), when
  92. the user types a period at an @...GET memvar PICTURE "9999.99", dBASE
  93. will proceed to the next command line.  This will not occur when the
  94. memory variable is initialized to two decimal places (that is, memvar =
  95. 0.00).  Only the integer portion of the number just entered will be
  96. stored to memvar if the period is typed.
  97.  
  98.  
  99. >>> @...GET...PICTURE
  100.  
  101.      The function "@B" is used with the @...SAY...GET statement to
  102. left-justify variables of numeric type.  It is most useful when SAYing
  103. a numeric field or memory variable that is more easily understood as a
  104. character string, such as a part number. Use of this FUNCTION with GET,
  105. however, causes a slight change in the way numeric variables are read
  106. from the screen that may cause some difficulties.
  107.      A numeric memory variable will default to a length of ten digits
  108. when initialized; however, if you are using the PICTURE function "@B"
  109. in an @...GET statement, a numeric memory variable will GET the width
  110. of the memory variable exactly as initialized, even if a template
  111. symbol is used.  Initializing a memory variable to zero will cause the
  112. GET statement to display one zero on the screen.  A READ command will
  113. allow one digit only to be entered to the memory variable.  This occurs
  114. whether the memory variable is initialized to 0 or 0000.  For example:
  115.  
  116. SET DELIMITERS ON
  117. w = 1234
  118. x = 0
  119. y = 0000
  120. @  9,0 GET w PICTURE "@B9999"
  121. @ 10,0 GET x PICTURE "@B9999"
  122. @ 11,0 GET y PICTURE "@B9999"
  123.  
  124. will produce:
  125.  
  126. :1234:
  127. :0:
  128. :0:
  129.  
  130. A READ command will allow four characters to be entered in the first
  131. variable, but only one character in the next two variables. If the "@B"
  132. function is used, initialize the memory variable to the proper length
  133. or the input may be truncated.
  134.  
  135.  
  136. >>> @...SAY...PICTURE
  137.  
  138.      To display a dollar-sign character ("$") in front of a numeric
  139. value and not have the possibility of a lot of "$"s filling the blank
  140. areas, do the following:
  141.  
  142. * ---To display a single "$".
  143. STORE 123.56 TO num
  144. @ 10,10 SAY "$"
  145. @ 10,11 SAY num PICTURE "99,999.99"
  146.  
  147. This will generate:
  148.  
  149. $  123.56
  150.  
  151. * ---The other option available is:
  152.  
  153. STORE 123.56 TO num
  154. @ 10,10 SAY num PICTURE "$$,$$$.$$"
  155.  
  156. This will generate:
  157.  
  158. $$$123.56
  159.  
  160.  
  161. >>> @...SAY using relative addressing
  162.  
  163.      We use the '$' function in dBASE II to control relative screen
  164. addressing with the @...SAY function.  For example, you can have a
  165. command file print the contents of a datafile to the screen as follows:
  166.  
  167. * ---This is dBASE II syntax.
  168. USE <datafile>
  169. DO WHILE .NOT. EOF
  170. *
  171.   @ 5,  5 SAY <Field1>
  172.   @ $+1,$ SAY <Field2>
  173.   @ $+1,$ SAY <Field3>
  174.   @ $+1,$ SAY <Field4>
  175.   SKIP
  176. *
  177. ENDDO [while .not. eof]
  178.  
  179.      The dBASE III utility, dCONVERT, is used to convert dBASE II
  180. programs, datafiles, etc. to dBASE III formats.  dCONVERT does not
  181. change the '$' function to ROW() and COL(); it leaves it alone.
  182. However, this will not cause any problems when executing the code in
  183. dBASE III.  dBASE III will treat the '$' function as a relative
  184. addressing function.
  185.  
  186.  
  187. >>> APPEND FROM <filename> [SDF/DELIMITED [WITH <delimiter>]]
  188.  
  189.      The DELIMITED form of the APPEND FROM command should be documented
  190. as having a WITH clause.  WITH is not mentioned in the reference
  191. section.  Below are a few examples:
  192.  
  193. Example 1. To read a comma delimited file in which the character
  194. strings are enclosed in double quotes:
  195.  
  196. APPEND FROM <filename> DELIMITED
  197.  
  198. or
  199.  
  200. APPEND FROM <filename> DELIMITED WITH "
  201.  
  202. Example 2. To read a comma delimited file in which the character
  203. strings are enclosed in single quotes:
  204.  
  205. APPEND FROM <filename> DELIMITED WITH '
  206.  
  207. Example 3. To read a comma delimited file in which the character
  208. strings are not enclosed at all:
  209.  
  210. dBASE III CANNOT READ A FILE OF THIS FORMT!
  211.  
  212.      Also, the syntax of the APPEND command does not include a WHILE
  213. option as the manual indicates.  The correct syntax is:
  214.  
  215. APPEND FROM <file name> [FOR <condition>]
  216. [SDF/DELIMITED [WITH <delimiter>]]
  217.  
  218.      APPEND FROM <textfile> SDF expects records in the text file to be
  219. terminated with a carriage return/line feed (0DH 0AH) pair, in this
  220. order.  If the order is reversed (0AH 0DH), dBASE III ignores the
  221. character following the carriage return.  This causes the first
  222. character of every record (after the first record) to be missed in the
  223. resultant database file.
  224.  
  225.  
  226.                              Menu 2
  227. >>> Closing Database Files
  228.  
  229.      Do not swap data disks without first closing all the open files on
  230. the original disk. Not doing so will cause the loss of data in buffers,
  231. and will also write a new entry in the directory of the new disk.  USE
  232. will close the currently SELECTed database file and CLOSE DATABASES
  233. will close all database files in all work areas.  CLEAR ALL also closes
  234. all open database files and will also release all memory variables.
  235. QUIT closes all files, releases all variables, and exits dBASE III.
  236. Choose one of these commands to close your files before swapping data
  237. disks.
  238.  
  239.  
  240. >>> COPY TO <filename> [SDF/DELIMITED [WITH <delimiter>]]
  241.  
  242.      (1) COPY TO <filename> DELIMITED does not enclose logical fields
  243. with the specified delimiters.  Numeric and date fields are also
  244. treated this way.  Date fields go out in the format YYYYMMDD.
  245.      (2) COPY TO <filename> DELIMITED WITH , encloses the character
  246. fields in commas and separates the fields with another comma.  This
  247. command behaves differently from dBASE II as shown below:
  248.  
  249. In dBASE II:
  250.   . USE file1
  251.   . COPY TO file2 DELIMITED WITH ,
  252.  
  253. will result in:
  254.   SANTA,CLAUS,NORTH POLE,ALASKA
  255.  
  256. In dBASE III:
  257.   . USE file1
  258.   . COPY TO file2 DELIMITED WITH ,
  259.  
  260. will result in:
  261.   ,SANTA,,,CLAUS,,,NORTH POLE,,,ALASKA,
  262.  
  263.  
  264. >>> COPY FILE <source filename> TO <target filename>
  265.  
  266.      The COPY FILE command copies files in 512-byte blocks whereas the
  267. COPY TO command will copy a .DBF file until the end-of-file. Therefore,
  268. the COPY FILE command will usually create a slightly larger file than
  269. the COPY TO command.  However, the COPY FILE is faster.
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276. >>> COPY STRUCTURE EXTENDED
  277.     CREATE FROM
  278.  
  279.      COPY STRUCTURE EXTENDED and CREATE FROM are fully implemented in
  280. dBASE III although not documented.  A brief description is given below.
  281.  
  282.      1) COPY STRUCTURE EXTENDED creates a file in whch the field names
  283. become the contents of one record.  The syntax for this COPY option is:
  284.  
  285. COPY STRUCTURE EXTENDED TO <new file>
  286.  
  287.      2) CREATE FROM forms a new database (.DBF) file in which the
  288. structure is determined by the contents of a file created with COPY
  289. STRUCTURE EXTENDED.  The syntax is:
  290.  
  291. CREATE <new file> FROM <structure extended file>
  292.  
  293.  
  294. >>> CREATE/MODIFY REPORT
  295.  
  296.      When you get the error message "Internal error - bucket overfilled"
  297. while in CREATE REPORT or MODIFY REPORT, you have too many characters in
  298. the report.  The maximum number of characters, or bucket size, is 1,440
  299. bytes.  This includes the number of characters in the following list:
  300.  
  301. Report heading          - plus one byte for each line
  302. Subtotal heading(s)     - plus one byte for each line
  303. Subtotal expression(s)  - plus one byte for each expression
  304. Field heading(s)        - plus one byte for each line
  305. Field expression(s)     - plus one byte for each expression
  306.  
  307.      The extra byte is a null terminator for each expression and
  308. heading.  When there are multiple lines in a heading, dBASE III
  309. separates them with a semicolon in the .FRM file.
  310.  
  311.  
  312. >>> Date conversion from dBASE II
  313.  
  314.      The dBASE BRIDGE manual (pages 23-24) lays out an elaborate scheme
  315. for converting dBASE II "dates" to dBASE III date fields. A much easier
  316. way is to simply convert the dBASE II database file to a dBASE III file
  317. and modify the structure from character to date field. All dates stored
  318. in a dBASE II character field as "MM/DD/YY" will directly convert to a
  319. dBASE III date field.
  320.  
  321.  
  322. >>> Dates that are blank
  323.  
  324.      CTOD() and DTOC() are intended to be inverse functions.  That is,
  325. if DTOC(date) = char, then CTOD(char) = date.  This is true in all
  326. circumstances except when the date is blank and the character string is
  327. " / / ".  To detect a blank date, you must use the DTOC() function
  328. rather than CTOD().  For example:
  329.  
  330.  
  331.  reg_date = CTOD("11/09/84")
  332.  ? reg_date = CTOD("11/09/84")
  333.  .T.
  334.  ? DTOC(reg_date) = "11/09/84"
  335.  .T.
  336.  * ---With a blank date the following occurs:
  337.  blank_date = CTOD("  /  /  ")
  338.  ? blank_date = CTOD("  /  /  ")
  339.  .F.
  340.  ? DTOC(blank_date) = "  /  /  "
  341.  .T.
  342.  
  343. As is evident from the example, the blank date is handled differently
  344. than the non-blank date.
  345.  
  346.  
  347. >>> Debugging tip
  348.  
  349.      The RETURN and CANCEL commands will release all PRIVATE memory
  350. variables when returning to the dot prompt.  This can make debugging
  351. difficult with versions 1.0 and 1.1 as you may want to check the status
  352. of variables used by the program.  The following debugging utility can
  353. be set up as a command file.  This utility, called Dot.PRG, will allow
  354. you to interactively enter commands, such as LIST MEMORY and LIST
  355. STATUS.  You can insert the command "DO Dot" at various problem points
  356. in your program.  When this command is encountered, you will be able to
  357. enter interactive commands without destroying the current environment
  358. of the program at runtime.  Once the program is fully debugged, you can
  359. remove the "DO Dot" command lines.
  360.  
  361. * Dot.PRG
  362. DO WHILE .T.
  363.   ACCEPT 'DOT  ' TO command
  364.   IF LEN( TRIM(command) ) = 0
  365.      EXIT
  366.   ENDIF
  367.   &command
  368. ENDDO
  369. RETURN
  370.  
  371.  
  372. >>> Demonstration Disk (RunTime+)
  373.  
  374.      In the Developer's Release of dBASE III, the dBRUN programs from
  375. the Demonstration Disk are not compatible with the full system.  Code
  376. crunched with DBC.COM from the Demonstration Disk can only be run with
  377. dBRUN from the Demonstration Disk.  Code crunched with DBC.COM from the
  378. Developer's Disk can only be run with the full dBASE III system or the
  379. dBRUN disk, purchased separately.  The error message:
  380.  
  381. No database is in USE.  Enter filename:
  382.  
  383. is a common indicator that the incorrect dBRUN or dBC is being used.
  384.  
  385.  
  386. >>> DISPLAY and LIST
  387.  
  388.      The DISPLAY and LIST commands are documented inthe manual as not
  389. having a FIELDS clause as part of the syntax, while the ASSIST and HELP
  390. menu options assume the FIELDS clause is required.  dBASE III will
  391. accept either syntax for these two commands.
  392.  
  393.  
  394. >>> Duplicate Keywords in Config.DB
  395.  
  396.      If two or more COMMAND = <value> lines are contained in the
  397. Config.DB file, only the last COMMAND will execute.  This is true of
  398. any duplicate <keyword> = <value> entry in the Config.DB file, with the
  399. exception of DELIMITERS, which can legitimately have two entries.  This
  400. is true for versions 1.0 and 1.1 of dBASE III.
  401.  
  402.  
  403. >>> FILE() function
  404.  
  405.      The FILE() function only searches the current directory.  SET PATH
  406. TO does not affect this function.  If other directories are to be
  407. searched, they must be supplied to the function.  For example,
  408.  
  409. * ---This will not find Data.dbf, if Data.dbf is in the
  410. * ---subdirectory ACCTS.
  411. SET PATH TO \DBASE\ACCTS
  412. IF FILE( "DATA.DBF" )
  413.   DO Process
  414. ENDIF
  415.  
  416. Workaround:
  417.  
  418. * ---This method will work.
  419. mpath = "\DBASE\ACCTS\"
  420. SET PATH TO &mpath
  421. IF FILE( mpath + "DATA.DBF" )
  422.   DO Process
  423. ENDIF
  424.  
  425.  
  426. >>> CTOD() Function
  427.  
  428.      The dBASE III Reference Manual does not clearly state that the
  429. CTOD() function will convert invalid dates to valid dates.  The day is
  430. adjusted first.
  431.  
  432. ? CTOD("02/29/85")
  433. 03/01/85  <------------ Extra day is added to month.
  434. ? CTOD("02/29/84")
  435. 02/29/84  <------------ Leap years are correct.
  436.  
  437. If the month is invalid, it is divided by twelve and the year is
  438. adjusted.  For example:
  439.  
  440.  
  441. ? CTOD("13/01/84")
  442. 01/01/85  <------------ Extra month is added to year.
  443. ? CTOD("12/32/84")
  444. 01/01/85  <------------ Extra day is added to month,
  445.                         extra month is added to year.
  446. ? CTOD("99/99/62")
  447.  
  448.  
  449.  
  450.  
  451.  
  452.                              Menu 3
  453. >>> FIND / SEEK
  454.  
  455.      FIND and SEEK are both used to move the record pointer of an
  456. indexed database to the first instance of the index key that matches
  457. the search argument.  FIND searches on a literal character string while
  458. SEEK searches on an expression the value of which may be character,
  459. date, or numeric.  The proper choice of command is related to the
  460. context and data type of the index key.  Generally, FIND will only be
  461. used to search for a literal character string and SEEK for all other
  462. searches. The following are some typical cases:
  463.  
  464.      (1) You have an index key that is character and are working from
  465. the dot prompt:
  466.  
  467.  . FIND Lee
  468.  or
  469.  . SEEK "Lee"
  470.  
  471.      (2) You have an index key that is numeric or date and are working
  472. from the dot prompt:
  473.  
  474.  . SEEK 1250
  475.  . SEEK CTOD('12/12/85')
  476.  
  477.      (3) You are working within a command file and are initializing a
  478. memory variable as a search key:
  479.  
  480. STORE SPACE(10) TO skey
  481. @ 10,10 SAY 'Enter value to search for' GET skey
  482. READ
  483. SEEK skey
  484.  
  485.      (4) You have a database field that is character, Code, and the
  486. contents are numeric digits and right-justified:
  487.  
  488. ACCEPT 'Enter code to search for' to skey
  489. SEEK SPACE(LEN(Code) - LEN(skey)) + skey
  490.  
  491.      (5) You are working with several databases and want to search for
  492. a key value in the current work area using a field variable from a
  493. non-active area with an alias name:
  494.  
  495.  
  496. SELECT 1
  497. USE File1 INDEX File1
  498. SELECT 2
  499. USE File2 INDEX File2
  500. SELECT File1
  501. SEEK File2->Field1
  502.  
  503.  
  504. >>> Function Keys
  505.  
  506.      F1 toggles the cursor control menu on and off in the following
  507. full screen edit modes.
  508.  
  509. APPEND    EDIT      MODIFY LABEL        MODIFY STRUCTURE
  510. BROWSE    CHANGE    MODITY REPORT
  511.  
  512.  
  513. >>> Get Diskspace
  514.  
  515.      In the Developer's Release use the DISKSPACE() function to get the
  516. amount of space left on the currently logged drive.  The DISKSPACE()
  517. will return the number of free bytes on the default drive as a numeric
  518. value.  dBASE III versions 1.0 and 1.1 do not have a function to return
  519. the amount of space left on the default drive.  So, to get the amount
  520. of diskspace in these versions, use the PC/MS-DOS utility CHKDSK and
  521. import the results into dBASE III.  The basic algorithm is as follows:
  522.  
  523.      1. Create or have available a general purpose database file called
  524. Util.DBF.  Util.DBF has one field called Util_line which is character
  525. type and has a length of 80.  This database file will be useful for any
  526. of these kinds of survey operations into PC/MS-DOS.
  527.  
  528.      2. RUN CHKDSK including the designator of the drive for which you
  529. want the space statistic for, and pipe the result into a text file
  530. entitled Util.TXT.  Piping is a PC/MS-DOS capability that allows the
  531. results of a program to be sent into a text file.  It is very useful
  532. for passing parameters between programs when there is no formalized
  533. interface.  The syntax is:
  534.  
  535. <DOS commmand>  >  <result text file>
  536.                 ^_____ DOS piping symbol
  537.  
  538. For more information on this capability, consult your PC/MS-DOS
  539. reference manual.
  540.  
  541.      3. APPEND the text file, Util.TXT, into the database file,
  542. Util.DBF.
  543.  
  544.      4. Assign to a memory variable the number of free bytes on the
  545. specified drive from Util.DBF.  This operation requires that you GOTO
  546. the record that contains the free disk space information and then
  547. extract the number of bytes from the field using the SUBSTR() function.
  548.  
  549.  
  550.  
  551.      The following is a LIST of Util.DBF with the results of a CHKDSK
  552. report.  When APPENDed into a database file, the first and last records
  553. are always blank.  Records 2 through 6 contain statistics about the
  554. currently logged disk drive.  Note that this is the currently logged
  555. DOS drive and not the DEFAULT drive SET in dBASE III.  Records 8 and 9
  556. contain statistics about the memory configuration of your computer.
  557. The number of bytes for each attribute of the drive and memory occupy
  558. positions 1 through 9 in the database field, Util_line.
  559.  
  560. Record#
  561.       1
  562.       2    9965568 bytes total disk space
  563.       3     155648 bytes in 4 hidden files
  564.       4      90112 bytes in 22 directories
  565.       5    6000640 bytes in 397 user files
  566.       6    3719168 bytes available on disk
  567.       7
  568.       8     524288 bytes total memory
  569.       9     122480 bytes free
  570.      10
  571.  
  572.      The code that will get the the number of free bytes on the
  573. specified disk drive is as follows:
  574.  
  575. SET SAFETY OFF
  576. RUN CHKDSK > Util.TXT
  577. USE Util
  578. ZAP
  579. APPEND FROM Util SDF
  580. GO 6
  581. diskspace = STR( SUBSTR( Util_line, 1, 9 ), 9 )
  582. USE
  583. SET SAFETY ON
  584. RETURN
  585.  
  586.  
  587. >>> Get Current Directory
  588.  
  589.     dBASE III has no facility to get the name of the current directory.
  590. To get it you must RUN the PC/MS-DOS command CD and import the results
  591. into dBASE III.  The basic algorithm is as follows:
  592.  
  593.      1. Create or have available a general-purpose database file called
  594. Util.DBF.  Util.DBF has one field called Util_line which is character
  595. type and has a length of 80.
  596.  
  597.      2. RUN the PC/MS-DOS command CD, piping the result into a text
  598. file entitled Util.TXT.
  599.  
  600.      3. APPEND the text file Util.TXT into the database file, Util.DBF.
  601.  
  602.      4. Assign to a memory variable the name of the current DOS
  603. directory from Util.DBF.
  604.  
  605. The code that will execute this algorithm is as follows:
  606.  
  607. SET SAFETY OFF
  608. RUN CD > Util.TXT
  609. USE Util
  610. ZAP
  611. APPEND FROM Util SDF
  612. currdir = TRIM( Util_line )
  613. SET SAFETY ON
  614. RETURN
  615.  
  616.  
  617. >>> Get Last Update Date and Time
  618.  
  619.      To get the date of last update for the currently SELECTed database
  620. file in the Developer's Release of dBASE III, use the LUPDATE()
  621. function.  LUPDATE() returns the date of last update as a value of date
  622. type.  dBASE III versions 1.0 and 1.1 currently do not have a function
  623. that returns the date of last update for the SELECTed database file.
  624. To get the date of last update in these versions of dBASE III, use the
  625. PC/MS-DOS command DIR, and import the results into dBASE III. The basic
  626. algorithm is as follows:
  627.  
  628.      1. Create or have available a general purpose database file called
  629. Util.DBF.  Util.DBF has one field called Util_line which is character
  630. type and has a length of 80.
  631.  
  632.      2. RUN the PC/MS-DOS command DIR with the name of your database
  633. file, piping the result into a text file entitled Util.TXT.
  634.  
  635.      3. APPEND the text file Util.TXT into the database file Util.DBF.
  636.  
  637.      4. Assign to a memory variable the date of last update from
  638. Util.DBF for your database file.
  639.  
  640. The code that will get the last update of the currently SELECTed
  641. database file is as follows:
  642.  
  643. SET SAFETY OFF
  644. RUN DIR <Yourfile>.DBF > Util.TXT
  645. USE Util
  646. ZAP
  647. APPEND FROM Util SDF
  648. lupdate = SUBSTR( Util_line, 25, 8 )
  649. luptime = SUBSTR( Util_line, 34, 6 )
  650. USE
  651. SET SAFETY ON
  652. RETURN
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661. >>> INPUT
  662.  
  663.      The INPUT command does not initialize a memory variable of any
  664. type if <RETURN> is pressed at its prompt.  The dBASE III manual says
  665. this will produce a syntax error (page 4-58).  What really happens is
  666. that a syntax error will result if the non-existent memvar is later
  667. referenced.
  668.  
  669.  
  670. >>> MACRO (&) Substitution in a Format (.FMT) File
  671.  
  672.      Macro (&) substitution will not work in a format (.FMT) file.  For
  673. example:
  674.  
  675. Structure for database: Macro.DBF
  676. Number of records:
  677. Date of last update: 05/01/85
  678. Field     Field name     Type          Width     Dec
  679.     1     FLD01          Character        10
  680.     2     FLD02          Character        10
  681.     3     FLD03          Character        10
  682. ** Total **                               30
  683.  
  684. * Program..: Macro.PRG
  685. * Note.....: This program will not display any field from
  686. *            the database file.
  687. CLEAR
  688. PUBLIC month
  689. month = "  "
  690. USE Macro
  691. ACCEPT "Enter two digits 01, 02, or 03: " TO month
  692. SET FORMAT TO Macro
  693. READ
  694. CLOSE FORMAT
  695. CLEAR
  696. RETURN
  697.  
  698. Macro.FMT contains one line:
  699. @ 05,30 SAY Fld&month
  700.  
  701.      If the SET FORMAT TO Macro, READ, and CLOSE FORMAT command lines
  702. are removed and DO Macro.FMT is inserted in their place, the program
  703. will execute as expected and the field will be displayed.
  704.  
  705.  
  706. >>> MEMO fields
  707.  
  708.      (1) MEMO fields are used to contain up to 5,000 characters of text
  709. information that is to be associated with a database record. Information
  710. may be read into a MEMO field using Ctrl-K-R and written to text files
  711. using Ctrl-K-W.  Information from MEMO fields can be displayed or
  712. printed by using LIST, DISPLAY, ?.  The field must be specified with
  713. these commands.  However, these commands cause the MEMO field to wrap
  714. at 50 columns.  The REPORT FORM may be used to output MEMO fields with
  715. line widths of more or less than 50 characters.
  716.  
  717.      (2) PACKing a database file with memo fields will not decrease the
  718. amount of disk space used by the .DBT file.  The command file below
  719. demonstrates how to remove the deleted records and free the unused disk
  720. space.
  721.  
  722. SET DELETED ON
  723. USE Filea
  724. COPY TO Temp
  725. CLOSE DATABASE
  726. ERASE Filea.dbf
  727. ERASE Filea.dbt
  728. RENAME Temp.dbf TO Filea.dbf
  729. RENAME Temp.dbt TO Filea.dbt
  730. SET DELETED OFF
  731.  
  732.      (3) When APPENDing FROM a database file with a memo field, the
  733. target .DBT file will be at least as large as the source .DBT regardless
  734. of how many records are APPENDed.  This is because the target .DBT file
  735. contains all the information that was contained in the source .DBT file.
  736. Be sure to note this any time you are moving records from one database
  737. file that contains memo fields to another.  There is a danger of
  738. unexpectedly filling a disk when doing this operation.
  739.  
  740.  
  741. >>> MODIFY STRUCTURE
  742.  
  743.      In MODIFY STRUCTURE, Ctrl-Home will bring up a menu on line 0 with
  744. the four choices listed below.
  745.  
  746. Bottom        Top       Field #     Menu
  747.  
  748.      They are selected with cursor control keys and <RETURN>.  Bottom
  749. moves the cursor to the last field, Top to the first.  Field # allows
  750. selection of a field number, then moves the cursor to it.  Menu toggles
  751. the cursor control menu off and on.  This feature is not documented
  752. under MODIFY STRUCTURE.
  753.  
  754.  
  755. >>> MODIFY STRUCTURE
  756.  
  757.      The "Warning" in the documentation on page 4-73 of dBASE III
  758. version 1.00 and WARNING of page 4-80 of dBASE III version 1.10 should
  759. read as follows:
  760.  
  761.      WARNING: Although you may change field names and field lengths,
  762.      if you change both at once, the data of the fields that have been
  763.      modified will not be appended into the new structure.
  764.  
  765.      Note that in the ASSIST mode, the following screen message is not
  766. entirely true, "Information in the database file is preserved where
  767. field names remain the same."  As noted above, if only field names are
  768. changed or only the length, the data is appended into the new structure.
  769. The correct procedure when both field name(s) and field length(s) need
  770. to be changed, is to modify the field name(s) first, and then re-enter
  771. MODIFY STRUCTURE and modify the field length(s).  Also, note that
  772. deleting a field (with Ctrl-U) has the same effect as modifying the
  773. field length.  Therefore, make deletions at the same time you make
  774. field length changes.
  775.  
  776.  
  777. >>> LABEL FORM command
  778.  
  779.      If TRIM() functions are the only expressions on a line in a LABEL
  780. FORM, dBASE III will return "*** Execution error on SUBSTR(): start
  781. point out of range" when the LABEL FORM encounters a record in which
  782. all TRIMmed fields are blank.
  783.  
  784.  
  785. >>>LOCATE and CONTINUE
  786.  
  787.      The LOCATE and CONTINUE commands cannot be used between two or
  788. more work areas at the same time.  If a LOCATE is issued in one work
  789. area then issued again in another work area, a CONTINUE in the original
  790. work area will result in a SKIP to the next record, not a CONTINUE.
  791. The following program segment illustrates how to LOCATE and CONTINUE
  792. between two data files.
  793.  
  794. SELECT 2
  795. USE Test
  796. SELECT 1
  797. USE Test1
  798. LOCATE FOR One > 1
  799. DO WHILE .NOT. EOF()
  800.   ? "FIELD Test1->One: " , One
  801.   SELECT 2
  802.   LOCATE FOR one > 1
  803.   DO WHILE .NOT. EOF()
  804.     ? "FIELD Test->One: ", One
  805.     SKIP
  806.     LOCATE NEXT 1000 FOR One > 1
  807.   ENDDO            ^-------------- should be larger
  808.   SELECT 1                         than last record
  809.   SKIP                             number in file.
  810.   LOCATE NEXT 1000 FOR One > 1
  811. ENDDO
  812.  
  813.      The dBASE III Reference Manual entry for MODIFY LABEL, states that
  814. "when you place several field names on one line of the LABEL contents
  815. screen, dBASE III eliminates the extra blank spaces and prints the
  816. label with only one space between fields."  This should read, "when you
  817. place several field names, separated by commas, on one line, etc."
  818. Concatenations of fields appear as they always do.
  819.  
  820.  
  821.                              Menu 4
  822. >>> Numeric fields with decimal places
  823.  
  824.      Although not documented, dBASE III expects the user to allow for a
  825. leading digit and a decimal point on numeric fields containing decimal
  826. places.  For example, a numeric field of two decimal places should not
  827. be defined any smaller than four digits in length -- one position for
  828. the leading digit, one position for the decimal point and two positions
  829. for the two decimal places.  If the structure for a numeric field does
  830. not allow for a leading digit (such as a width of three and two decimal
  831. places), numeric input to the numeric field will always be stored as
  832. zero.  Also, if other numeric fields follow this field, they might
  833. automatically be zeroed out when numeric data is entered to the first
  834. field.
  835.  
  836.  
  837. >>> Numeric input of large numbers
  838.  
  839.      If a variable is initialized to zero, dBASE III does not allow
  840. input larger than 10 digits when using the @...GET command, even if the
  841. PICTURE clause is used.  For example:
  842.  
  843. x = 0
  844. @ 5,5 SAY "Enter digits" GET x PICTURE "99999999999"
  845. *      (There are eleven 9's) ----------^
  846. READ
  847.  
  848. The display is:
  849.  
  850. Enter digits           0
  851.  
  852. If an eleven digit value is entered, the display is:
  853.  
  854. Enter digits  **********  (10 asterisks)
  855.  
  856. This can be avoided by initializing 'x' to a value greater than ten
  857. digits (such as, 1000000000).  This problem does not occur if a field
  858. is used rather than a memory variable.
  859.  
  860.  
  861. >>> PARAMETERS, passing Fields
  862.  
  863.     In the documentation concerning PARAMETERS when used in conjunction
  864. with the DO <filename> [WITH <parameter list>] command, page 4-76 of
  865. the version 1.0 manual states, "A passed parameter may be any legitimate
  866. expression."  Also, in the Glossary (page 7-3) the definition for
  867. Expression is, "Expression may consist of a field, a memory variable,
  868. a function, a constant, or any combination thereof."  However, when a
  869. DO is invoked with a field in the parameter list, dBASE III will give
  870. the message, "Variable not found."  In order to use a field name in the
  871. parameter list, you must use the Alias -> Fieldname form.  For example:
  872.  
  873. USE Filea
  874. DO <Filename> WITH Filea -> Field1
  875.  
  876. will work, but the following will not.
  877.  
  878. USE Filea
  879. DO <Filename> WITH Field1
  880.  
  881.                              Menu 5
  882. >>> PRIVATE
  883.  
  884.      In dBASE III, all variables are PRIVATE to the routine in which
  885. they are initialized unless otherwise declared.  Variables created at
  886. the dot prompt will automatically be PUBLIC no matter how they are
  887. declared.  Declaring a variable PRIVATE in a command file hides any
  888. outer-level definition of a variable with the same name from the current
  889. routine.  It also hides any deeper-level routines from viewing any
  890. outer-level definition of a variable with the same name. In the example
  891. below, programs B.PRG and C.PRG do not have access to variable X in
  892. program A.PRG.  Program C.PRG, therefore, will display X with a value
  893. of 15 and not 10.  Program A.PRG, however, will diplay X with the old
  894. value of 10 even after executing program B.PRG.
  895.  
  896. * A.PRG
  897. x = 10
  898. DO B    ----------> * B.PRG
  899. ? x                 PRIVATE x
  900. RETURN              x = 15
  901.                     DO C    ----------> * C.PRG
  902.                     RETURN              ? x
  903.                                         RETURN
  904.  
  905.      In programming, you will want to declare a variable PRIVATE in a
  906. subroutine if you do not want this variable to interfere with an
  907. outer-level variable having the same name.  To illustrate the use of
  908. PRIVATE, the command files MAIN.PRG and SUB.PRG are listed below, with
  909. the displayed output.  Notice that all the variables are released when
  910. MAIN.PRG returns control to the dot prompt.  Also notice that the
  911. variables initialized in MAIN.PRG are PRIVATE in the memory display
  912. even though they are never explicitly declared.  Lastly, notice that
  913. the value assigned to height in SUB.PRG is not returned to MAIN.PRG,
  914. but the value assigned to area in SUB.PRG is returned.  This is because
  915. height is declared PRIVATE in SUB.PRG and area is not.
  916.  
  917. LISTINGS:
  918.  
  919. * MAIN.PRG
  920. * --------
  921. area = 0
  922. height = 304
  923. ? "Before call to SUB:"
  924. ? "-------------------"
  925. DISPLAY MEMORY
  926. DO Sub    ------------------> * SUB.PRG
  927. ? "After call to SUB:"        * -------
  928. ? "------------------"        PRIVATE height
  929. DISPLAY MEMORY                height = 30
  930. RETURN                        area = 10 * 20 * height
  931. * EOF: MAIN.PRG               ? "Inside SUB:"
  932.                               ? "-----------"
  933.                               DISPLAY MEMORY
  934.                               RETURN
  935.                               * EOF: SUB.PRG
  936.  
  937. OUTPUT:
  938. Before call to SUB:
  939. -------------------
  940. AREA        priv  N           0  (         0.00000000)
  941. HEIGHT      priv  N         304  (       304.00000000)
  942.     2 variables defined,       18 bytes used
  943.   254 variables available,   5982 bytes available
  944.  
  945. Inside SUB:
  946. -----------
  947. AREA        priv  N        6000  (      6000.00000000)
  948. HEIGHT      priv  (hidden)  N         304  (       304.00000000)
  949. HEIGHT      priv  N          30  (        30.00000000)
  950.     3 variables defined,       27 bytes used
  951.   253 variables available,   5973 bytes available
  952.  
  953. After call to SUB:
  954. ------------------
  955. AREA        priv  N        6000  (      6000.00000000)
  956. HEIGHT      priv  N         304  (       304.00000000)
  957.     2 variables defined,       18 bytes used
  958.   254 variables available,   5982 bytes available
  959.  
  960. lines will display:
  961.  
  962.     0 variables defined,        0 bytes used
  963.   256 variables available,   6000 bytes available
  964.  
  965.  
  966. >>> PROCEDURE -- Calling Command Files from Procedures within dBASE III
  967.  
  968.      To call a command file from a procedure, you must follow a few
  969. rules.
  970.  
  971.      Rule 1:  The command file cannot have the same name as any of the
  972. procedres in the file even if the extension is included as part of the
  973. filename.  An attempt to do this will cause the inappropriate error
  974. message, "Unrecognized phrase/keyword in command."  For example:
  975.  
  976. * Proc_ne.PRG
  977. PROCEDURE One
  978.   * ---The next command will not work because
  979.   * ---Two is a procedure in this file.
  980.   DO Two.PRG
  981. RETURN
  982. *
  983. PROCEDURE Two
  984.   * ---The next command will work.
  985.   DO Three.PRG
  986. RETURN
  987. * EOF: Proc_One.PRG
  988.  
  989.  
  990.  
  991.      This can be avoided by renaming either the command file or
  992. procedure.  To avoid this problem you might want to begin procedure
  993. names with a prefix that command files will not have.  For instance, in
  994. the previous example the procedures could have been called P_One and
  995. P_Two.
  996.  
  997.      Rule 2:  Once the command file is invoked from a procedure file,
  998. it must not DO another procedure in the procedure file.  Instead, it
  999. should RETURN to the calling procedure. Otherwise, the called procedure
  1000. will usually execute, but an error message will be displayed for a
  1001. command line that does not exist.
  1002.  
  1003.      Rule 3:  Internal procedure calls (that is, a procedure that calls
  1004. either itself or another procedure in the same file) must be kept to
  1005. eighteen nested calls or less.  The nineteenth call attempt will return
  1006. execution to the calling command file with no error message.
  1007.  
  1008.  
  1009. >>> PROW()
  1010.  
  1011.      When issuing SET PRINT ON, PROW() will be set to 2, regardless of
  1012. its previous setting.  An EJECT will reset PROW() to 2, not 0.  Issuing
  1013. an EJECT with SET PRINT OFF will reset PROW() to 0.  When SET PRINT is
  1014. ON, PROW() may never equal 0 or 1.  Any attempt to test for PROW() = 0
  1015. or PROW() = 1 will work only when SET PRINT is OFF.
  1016.  
  1017.  
  1018.                              Menu 6
  1019. >>> PUBLIC
  1020.  
  1021.     PUBLIC is used to declare memory variables as global and to prevent
  1022. their release when control is returned to the dot prompt.  PUBLIC
  1023. variables must be declared prior to being initialized, and once
  1024. declared, these variables will be assigned a logical false value until
  1025. initialized.  PUBLIC variables can be re-declared as PUBLIC without
  1026. losing the values already stored in them.  In programming, declaring
  1027. all variables as PUBLIC in the main routine would make dBASE III behave
  1028. similar to dBASE II.  However, there is one difference in dBASE III,
  1029. PUBLIC variables can only be released by the CLEAR MEMORY, CLEAR ALL,
  1030. and RELEASE <variable list> commands, but not the RELEASE ALL command.
  1031.  
  1032.  
  1033. >>> Ramdisks
  1034.  
  1035.      There are several options for users who wish to use a ramdisk in
  1036. combination with dBASE III.
  1037.  
  1038.      1. For faster operation of applications that utilize routines
  1039. stored in the DBASE.OVL file, you may wish to put the .OVL in a ramdisk.
  1040.  
  1041.         (a) The minimum drive size will have to be in excess of 181,000
  1042. bytes.  The DBASE.OVL file for version 1.1 is 180,736 bytes.  The total
  1043. amount of RAM in your machine must be more than 440,000 bytes in order
  1044. to do this.  Additionally, if you are using a CONFIG.DB, it must be
  1045. present on the drive where .OVL resides.
  1046.  
  1047.         (b) Boot dBASE III from the ramdisk by calling for the DBASE.COM
  1048. from the drive on which it resides. For example: drive D: is the ramdisk
  1049. and the DBASE.COM is on the C: drive.
  1050.  
  1051. C> D:
  1052. D> C:DBASE
  1053.  
  1054.      2. It may be a very useful area for procedure or command files to
  1055. be run from, increasing the speed of processing.  Prior to entering
  1056. dBASE III, copy the appropriate files to the ramdisk.  Once in dBASE
  1057. III, SET the DEFAULT TO the ramdisk drive and proceed.
  1058.  
  1059.      3. It is also useful as a small work area to manipulate utility
  1060. and temporary files.  The useage tips on getting the current directory
  1061. or diskspace are good examples of where a small ramdisk would be
  1062. extremely useful and time efficient.
  1063.  
  1064.  
  1065. >>> RELEASE, incorrect syntax
  1066.  
  1067.      The syntax "RELEASE ALL LIKE <skeleton>,<skeleton>" is incorrect
  1068. but will not produce an error message.  The correct syntax is either
  1069. RELEASE <memvar list> or RELEASE ALL LIKE <skeleton>.  You may use
  1070. wildcard characters in the RELEASE ALL LIKE form of the command, but
  1071. dBASE III will ignore any <skeleton> after the first comma.
  1072.  
  1073.  
  1074. >>> RELEASE ALL, CLEAR MEMORY
  1075.  
  1076.      RELEASE ALL and CLEAR MEMORY are not equivalent commands as the
  1077. dBASE III manual states.  CLEAR MEMORY clears all memory variables,
  1078. regardless where they were initialized.  RELEASE ALL, however, will
  1079. release all memory variables except those declared PUBLIC or
  1080. initialized in a nested command file.
  1081.  
  1082.  
  1083. >>> REPLACE
  1084.  
  1085.      REPLACE ALL does not replace all records correctly if an index is
  1086. in use and the key field is replaced.  Only the first record and those
  1087. that logically follow the new value will be replaced.  This occurs
  1088. because the index is automatically updated (in-place key updating) when
  1089. it is edited.  The record pointer moves to the record following the new
  1090. position, not to the record following the old position.  This can be
  1091. illustrated in the example given below (the data file has five records
  1092. with the field CHARS-C-1, and is indexed on this field):
  1093.  
  1094.  . LIST
  1095.  Record#  CHARS
  1096.        1  a
  1097.        2  b
  1098.        3  c
  1099.        4  i
  1100.        5  j
  1101.  
  1102. . REPLACE ALL Chars WITH 'd'
  1103.        3 records replaced
  1104. . LIST
  1105.        2  b
  1106.        3  c
  1107.        1  d
  1108.        4  d
  1109.        5  d
  1110.  
  1111.      The manual warns against block replacements to the key field.  The
  1112. correct procedure would be to REPLACE with no indexes in use, open the
  1113. indexes with SET INDEX TO, and then REINDEX.
  1114.  
  1115.  
  1116. >>> REPORT FORM--Dates
  1117.  
  1118.      If you have a date-oriented report and you need to have it grouped
  1119. by week, the following discussion will assist you.  The grouping of
  1120. dates into weeks has two requirements.  First, the database file you
  1121. are reporting from must be INDEXed on the date field that is being
  1122. grouped on.  Second, as the group expression in your REPORT FORM, you
  1123. must have an expression that returns as its value the first day of the
  1124. week for each date field.  The expression is as follows:
  1125.  
  1126. Yourdate - ( DOW( Yourdate ) - 1 )
  1127.  
  1128.      When given any date value, this expression returns the date of the
  1129. previous Sunday.  It does this by subtracting from your date field the
  1130. number of days that have passed since the last Sunday, the first day of
  1131. the week in the dBASE III calendar.  This value is obtained by
  1132. subtracting 1 from the result of the DOW() function.  If you wish to
  1133. have the week you are grouping on start on a later day such as Monday,
  1134. subtract more from the result of the DOW() function.  For example,
  1135. Monday would be DOW() - 2, Tuesday DOW() - 3, and so on.
  1136.  
  1137.  
  1138. >>> REPORT FORM HEADING
  1139.  
  1140.      There appears to be some confusion about the use of the HEADING
  1141. option to the REPORT FORM command.  The argument of the HEADING
  1142. statement is a character expression and, therefore, can contain any
  1143. combination of memory variables, field variables including aliases, and
  1144. functions that evaluate to a value of character type.  This means that
  1145. macro substitution is not necessary to in order to use variable data
  1146. for the REPORT FORM in question.  As a typical example:
  1147.  
  1148. * ---Set up header string.
  1149. title = "Sample Report Number 1"
  1150. *---Run the report.
  1151. REPORT FORM YourRpt HEADING title
  1152.  
  1153.      If the HEADING argument is a field variable from the database file
  1154. being REPORTed on, the value of the HEADING will be the field value
  1155. from the record being pointed to when the REPORT FORM is invoked.  For
  1156. example, if the current record number is 5 and a REPORT FORM is run
  1157. with no scope, the HEADING value is set from record 5 and then the
  1158. record pointer is reset to the top of file.  The ability to use a
  1159. database field as the HEADING argument presents some interesting
  1160. possibilites. Suppose you have a master client and transaction file.
  1161. You wish to have a transaction listing for a particular client with
  1162. that client's name at the top of the REPORT FORM.  The transactions
  1163. database file is INDEXed in client number order.
  1164.  
  1165. * ---Open database files.
  1166. SELECT 1
  1167. USE Client
  1168. SELECT 2
  1169. USE Transaction INDEX Transaction
  1170. SELECT Client
  1171. * ---Get the client to report on.
  1172. LOCATE FOR Name = "Smith"
  1173. * ---Report client's transactions.
  1174. SELECT Transaction
  1175. REPORT FORM Transaction HEADING Client->Name;
  1176. WHILE Number = Client->Number
  1177.  
  1178.  
  1179. >>> REPORT FORM, MODIFY REPORT
  1180.  
  1181.      (1) The report generator will right-justify field headings for
  1182. numeric fields when the report is run.
  1183.  
  1184.      (2) If the PLAIN clause is specified with REPORT FORM TO PRINT, no
  1185. page ejects occur.  The report prints through to the end without page
  1186. breaks.
  1187.  
  1188.      (3) MODIFY REPORT will allow the number of decimal places to be
  1189. changed from the default.  If this is done and the report is run,
  1190. everything is as expected.  However, if the report is modified again,
  1191. the number of decimal places reverts to the default when the cursor
  1192. reaches the "# decimal places" field.
  1193.  
  1194.      (4) Although not documented in the manual or in the cursor control
  1195. menu, Ctrl-N inserts a column in a report being created or modified.
  1196. However, its counterpart (Ctrl-U which deletes a column) is documented
  1197. and included in the help menu.
  1198.  
  1199.  
  1200. >>> REPORT FORM <filename> PLAIN
  1201.  
  1202.      The PLAIN option of the REPORT FORM command will cancel out the
  1203. HEADING option when these two are used in the same command line.
  1204. Therefore, do not use these two options in the same command.  For
  1205. example, the following command line will not print the HEADING "Week
  1206. of May 6, 1985":
  1207.  
  1208. REPORT FORM Wksales PLAIN HEADING "Week of May 6, 1985" TO PRINT
  1209.  
  1210.  
  1211.  
  1212.  
  1213. >>> RANGE command
  1214.  
  1215.      The dBASE III Reference Manual states that RANGE may be used to
  1216. specify lower and upper bounds for date variables, but does not clarify
  1217. that the arguments of the RANGE clause involving literal dates must be
  1218. in the form, CTOD("mm/dd/yy").  For example:
  1219.  
  1220. @ 10,10 GET Mdate RANGE CTOD("01/01/85"), CTOD("01/01/86")
  1221.  
  1222.  
  1223. >>> REPORT FORM
  1224.  
  1225.      The semicolon is not documented as functioning as a Carriage
  1226. Return/Line-Feed in certain parts of REPORT FORMs.
  1227.  
  1228.  
  1229.                              Menu 7
  1230.  
  1231. >>> Reserved Device Names in MS-DOS
  1232.  
  1233.      The MS-DOS manual specifies that certain names have a special
  1234. meaning to MS-DOS.  Do not use these reserved device names as dBASE III
  1235. filenames: CON, AUX, COM1, COM2, LPT1, PRN, LPT2, LPT3, or NUL.  This
  1236. applies to database files, index files, command files, format files, or
  1237. form files.  Various error messages will result when files with any of
  1238. these names are accessed.
  1239.  
  1240.  
  1241. >>> Reserved words
  1242.  
  1243.      Page 1-138 of the tutorial in the first edition of the manual uses
  1244. a sample routine which creates a memory variable with the name
  1245. 'continue.'  Since this is a reserved word, dBASE III will give the
  1246. message, "No database in USE, enter filename."  dBASE III is assuming
  1247. you intend to CONTINUE on a LOCATE command.  This will only happen if
  1248. you use the <variable> = <value> frm of assignment; dBASE III will
  1249. execute correctly when you use the STORE <value> TO <variable> form.
  1250. Other words that will not work with the first syntax are: AVERAGE,
  1251. COUNT, and SUM.
  1252.  
  1253.  
  1254. >>> ROW(), COL()
  1255.  
  1256.      After a READ, the ROW() function always returns 24; however, the
  1257. COL() function does not change.  For example:
  1258.  
  1259. SET TALK OFF
  1260. var = SPACE(2)
  1261. @ 5,40 GET var
  1262. ? ROW(), COL()      <--- This returns 6 and 3.
  1263. READ
  1264. ? ROW(), COL()      <--- This returns 24 and 3.
  1265.  
  1266.  
  1267.  
  1268. >>> RUN (or !)
  1269.  
  1270.      The RUN command requires that COMMAND.COM be in the boot drive or
  1271. the directory indicated by SET COMSPEC.  Otherwise, the incorrect error
  1272. message "Insufficient memory" is displayed.
  1273.  
  1274.  
  1275. >>> RUN COMMAND
  1276.  
  1277.      You can get the equivalent to Framework's DOS Access in dBASE III
  1278. by issuing RUN COMMAND. This will leave you at the DOS operating system
  1279. level and will allow you to enter any DOS commands.  To get back to the
  1280. dBASE III dot prompt, type EXIT.
  1281.  
  1282.  
  1283. >>> SET ALTERNATE TO
  1284.  
  1285.      dBASE III will not send a linefeed (that is, CHR(10)) to an
  1286. alternate file (WordPerfect looks for this linefeed character in its
  1287. mail merge program).  The following command file:
  1288.  
  1289. SET ALTERNATE TO x
  1290. SET ALTERNATE ON
  1291. ?? "first LF"
  1292. ?? CHR(10)
  1293. ?? "second LF"
  1294. SET ALTERNATE OFF
  1295. CLOSE ALTERNATE
  1296.  
  1297. will generate the following test file:
  1298.  
  1299. first LFsecond LF
  1300.  
  1301. As you can see, there is no linefeed in the file.
  1302.  
  1303.  
  1304. >>> SET COLOR
  1305.  
  1306.     (1) To get enhanced video to be black on black, use the command SET
  1307. COLOR TO x/y,0+/0.  Black on black is frequently used to allow user
  1308. input without displaying the characters on the screen, as with entry of
  1309. a password.
  1310.  
  1311.      (2) The command: SET COLOR TO  ,<cr>  will produce black on black,
  1312. even if there is no space after the comma.
  1313.  
  1314.      (3) The asterisk (*) used with the SET COLOR command allows you to
  1315. have blinking characters on the screen.  The asterisk must be used in
  1316. conjunction with a color parameter.  For example:
  1317.  
  1318. SET COLOR TO 6*/1,7/4,6
  1319.  
  1320. or:
  1321.  
  1322. SET COLOR TO GR*/B,W/R,GR
  1323.  
  1324.  
  1325. >>> SET COLOR TO on the Compaq computer
  1326.  
  1327.    SET COLOR TO U on the Compaq computer will not generate underlining.
  1328. Instead, SET COLOR TO U and SET COLOR TO I give quarter intensity.
  1329. Using U+ or I+ will generate half intensity.  You will not get the
  1330. monochrome attributes, because the Compaq monitor is operating as if
  1331. it where color.
  1332.  
  1333.  
  1334. >>> SET CONSOLE ON/OFF
  1335.  
  1336.      The SET CONSOLE ON/OFF command behaves differently in dBASE III
  1337. than it does in dBASE II.  Specifically, it has no effect when issued
  1338. at the dot prompt, and if SET CONSOLE OFF is issued in a command file
  1339. that neglects to SET CONSOLE ON, dBASE III will automatically set the
  1340. console back on upon the termination of execution of that file.  This
  1341. includes normal termination as well as termination by means of pressing
  1342. the escape key.
  1343.  
  1344.  
  1345. >>> SET DEBUG ON
  1346.  
  1347.      SET DEBUG ON overrides SET CONSOLE OFF and output will be echoed
  1348. to the screen.
  1349.  
  1350.  
  1351. >>> SET DELETED
  1352.  
  1353.      SET DELETED in dBASE III applies to all commands, unlike dBASE II,
  1354. where certain commands ignore the status of SET DELETED.  In dBASE III
  1355. you are permitted to COPY, APPEND and REPORT deleted records if DELETED
  1356. is set OFF.
  1357.  
  1358.  
  1359. >>> SET DOHISTORY ON/OFF (Developer's Release)
  1360.  
  1361.      If your dBASE III Developer's Release Reference Manual does not
  1362. contain page 4-115A in the Commands section which explains the use of
  1363. SET DOHISTORY, the following documents the command.  SET DOHISTORY
  1364. determines whether or not commands from command files are recorded in
  1365. HISTORY.
  1366.  
  1367. Syntax:   SET DOHISTORY ON/OFF
  1368.  
  1369. Defaults: SET DOHISTORY is normally OFF
  1370.  
  1371. Usage:    When SET DOHISTORY is ON, commands that were executed from
  1372.           within command files are stored in HISTORY.  You can then
  1373.           edit these in full-screen edit mode and execute them.  Note
  1374.           that SET DOHISTORY has no effect on commands you issue from
  1375.           the dot prompt.
  1376.  
  1377.  
  1378. Tips:     In conjunction with SUSPEND, SET DOHISTORY is useful for
  1379.           debugging.  However, because SET DOHISTORY slows down command
  1380.           file execution, use it only when debugging.
  1381.  
  1382. See Also: DISPLAY HISTORY, LIST HISTORY, RESUME, SET DEBUG, SET ECHO,
  1383.           SET HISTORY, SET STEP, SUSPEND
  1384.  
  1385.  
  1386. >>> SET FILTER TO
  1387.  
  1388.      (1) The SORT command will only sort those records that meet the
  1389. filter condition.  The INDEX command will index all records in the file
  1390. whether or not they meet the filter condition.  However, a FIND command
  1391. will return "No find" if the key falls outside the scope of FILTER.
  1392.  
  1393.      (2) Some users are confused regarding the performance that may be
  1394. expected when using the SET FILTER TO command.  The database file is
  1395. not smaller in size when a filter is set.  Consequently, activities
  1396. that access the file are not proportionately faster.  Commands that
  1397. operate on the FILTERed set of records must still scan the entire
  1398. database file.
  1399.  
  1400.  
  1401. >>> SET MENUS ON/OFF
  1402.  
  1403.      The default for SET MENUS is OFF.  However, ASSIST leaves MENUS
  1404. SET ON even if they were off prior to entering ASSIST.
  1405.  
  1406.  
  1407. >>> SET PROCEDURE TO, PARAMETERS, PROCEDURE
  1408.  
  1409.      The following program and procedure files illustrate the use of
  1410. parameter passing with procedures.  FUTVALUE.PRG calculates the future
  1411. value of an investment and the future value of an annuity with the use
  1412. of the BUSINESS.PRG procedure file.  Notice how the parameters can be
  1413. passed to BUSINESS.PRG. They can either be literal numbers, expressions
  1414. or variables.  Also, notice that the PARAMETERS command is included
  1415. after each PROCEDURE that receives parameters.
  1416.  
  1417. LISTINGS:
  1418.  
  1419. * FUTVALUE.PRG
  1420. * ------------
  1421. SET TALK OFF
  1422. SET FIXED ON
  1423. SET PROCEDURE TO  Business
  1424. *
  1425. * { Calculate future value of an investment
  1426.  
  1427. result = 0.00
  1428. DO  FV  WITH  6000.00, 8.5, 4, 5, result
  1429. ? result
  1430. *
  1431. * { Calculate future value of regular deposits (Annuity)
  1432.  
  1433. result = 0.00
  1434. DO  FVA  WITH  150.00, 7.0, 12, 2, result
  1435. ? result
  1436. *
  1437. CLOSE PROCEDURE
  1438. SET FIXED OFF
  1439. SET TALK ON
  1440. RETURN
  1441. * EOF: FUTVALUE.PRG
  1442.  
  1443.  
  1444. * BUSINESS.PRG  { Library of business procedures
  1445.  
  1446. * ------------
  1447. *
  1448.  PROCEDURE  FV  { Calculate future value of an investment
  1449.  
  1450.  PARAMETERS  amount, rate, periods, years, result
  1451.   rate = rate / periods / 100
  1452.   result = amount * (1 + rate)  (periods * years)
  1453.   result = ROUND( result, 2 )
  1454.  RETURN
  1455. *
  1456.  PROCEDURE FVA { Calculate future value of regular deposits
  1457.  PARAMETERS  amount, rate, periods, years, result
  1458.   rate = rate / periods / 100
  1459.   result = amount * ( (1 + rate)  (periods *;
  1460.            years) - 1 ) / rate
  1461.   result = ROUND( result, 2 )
  1462.  RETURN
  1463. *
  1464. * EOF: BUSINESS.PRG
  1465.  
  1466. OUTPUT:
  1467.  
  1468. 9136.77
  1469. 3852.15
  1470.  
  1471.  
  1472.                              Menu 8
  1473. >>> SET RELATION TO
  1474.  
  1475.      The SET RELATION TO command takes precedence over the SET FILTER
  1476. TO and SET DELETED ON commands.  That is, information from a related
  1477. database file will be displayed if addressed with an alias name, even
  1478. if that record has been filtered out with the SET FILTER TO command or
  1479. with SET DELETED ON.  Please note that because of this, SETting FILTER
  1480. TO .NOT. DELETED() in another work area to exclude deleted records in
  1481. that work area will not work if that record is accessed with the alias
  1482. name.  The following examples demonstrate that deleted and filtered
  1483. records may be accessed if they are addressed with SET RELATION TO.
  1484. Both database files consist of one 10-byte character field called One.
  1485.  
  1486.  
  1487.  
  1488. SELECT 1
  1489. USE Test1
  1490. SELECT 2
  1491. USE Test2
  1492. INDEX ON One to Test2
  1493. DELETE ALL                       <-- Delete all from Test2.
  1494. SET FILTER TO .NOT.  DELETED()  <-- Filter deleted records.
  1495. SELECT 1
  1496. SET RELATION TO One INTO Test2  <-- SET RELATION.
  1497. ?  One, B->One
  1498.  
  1499. AAAAAAAAAA AAAAAAAAAA
  1500.            ^--------------------- Field displays even though
  1501.                                        it is deleted and filtered
  1502.                                        from the Test2.DBF.
  1503.  
  1504.  
  1505. >>> SET RELATION TO <expression> INTO <alias>
  1506.  
  1507.      (1) SET RELATION TO relates two database files by means of an
  1508. expression.  It can be used in conjunction with REPORT, LABEL, LIST,
  1509. and many other commands to view information from more than one file.
  1510. In the examples below, the command files on the left and right sides
  1511. are identical in function.  You will notice that it takes several more
  1512. lines of code to accomplish the same task if the SET RELATION TO
  1513. command is not used.
  1514.  
  1515. Example 1:
  1516.  
  1517. * ---Without SET RELATION.    * ---Using SET RELATION.
  1518. * ---Linked by RECNO().       * ---Linked by RECNO().
  1519. SELECT 2                      SELECT 2
  1520. USE Address                   USE Address
  1521. GO BOTTOM                     SELECT 1
  1522. STORE RECNO() TO last         USE Names INDEX Alpha
  1523. SELECT 1                      SET RELATION TO RECNO() INTO Address
  1524. USE Names INDEX Alpha         DO WHILE .NOT. EOF()
  1525. DO WHILE .NOT. EOF()             ? Name,Address->Phone
  1526.    STORE RECNO() TO rec          SKIP
  1527.    SELECT Address             ENDDO
  1528.    IF rec <= last
  1529.       GO rec
  1530.    ELSE
  1531.       GO last
  1532.       SKIP
  1533.    ENDIF
  1534.    SELECT Names
  1535.    ? Name,Address->Phone
  1536.    SKIP
  1537. ENDDO
  1538.  
  1539.  
  1540.  
  1541.  
  1542.  
  1543. Example2:
  1544.  
  1545. * ---Without SET RELATION     * ---Using SET RELATION.
  1546. * ---Linked on key field.     * ---Linked on key field.
  1547. SELECT 2                      SELECT 2
  1548. USE Detail INDEX Custnbr      USE Detail INDEX Alpha
  1549. SELECT 1                      SELECT 1
  1550. USE Customer                  USE Customer
  1551. DO WHILE .NOT. EOF()          SET RELATION TO  Number  INTO  Detail
  1552.    STORE Number TO mkey       DO WHILE .NOT. EOF()
  1553.    SELECT Detail                 ? Name,Detail->Phone
  1554.    SEEK mkey                     SKIP
  1555.    SELECT Customer            ENDDO
  1556.    ? Name,Detail->Phone
  1557.    SKIP
  1558. ENDDO
  1559.  
  1560.      To use SET RELATION TO with reports and labels, set the relation
  1561. when the report or label is executed.  When creating or modifying a
  1562. report or label, only the structure of the active database file in the
  1563. selected work area will be displayed at the top of the screen, so a
  1564. listing of the unselected database file will be necessary.  To specify
  1565. fields from the unselected file, use the <alias>-><fieldname> form.  In
  1566. order to print the report or label properly, both files will have to be
  1567. in use and the relation will have to be set before the REPORT r LABEL
  1568. command is issued.
  1569.  
  1570.  
  1571. >>> SET UNIQUE ON/OFF
  1572.  
  1573.     The SET UNIQUE command determines whether duplicate key values will
  1574. be stored in index files.  The use of SET UNIQUE affects:
  1575.  
  1576.      1. How the INDEX ON command constructs the named index file.
  1577.      2. How the REINDEX and PACK commands rebuild all open index files
  1578. in the currently selected work area.
  1579.      3. How all open index files are maintained when the active database
  1580. is updated (such as in APPEND, BROWSE, CHANGE, EDIT, or REPLACE).
  1581.  
  1582.      There is a tendency to believe that SET UNIQUE only needs to be
  1583. used when creating an index file.  SET UNIQUE does not work this way.
  1584. The "uniqueness" of an index file is in no way attached to the file.
  1585. When additions, deletions, or changes to key information are made to
  1586. the database file, the index file must be open and SET UNIQUE must be
  1587. ON or OFF (default).  It is not possible to maintain index files of
  1588. both unique and non-unique types for the same database file, unless one
  1589. of them is recreated with SET UNIQUE ON or OFF every time a record is
  1590. updated.  Another item to consider when using "unique" and "non-unique"
  1591. index files is when they are used in different SELECTed work areas.
  1592. Updating indexed database files in different work areas will require
  1593. that UNIQUE be SET to the appropriate value for each SELECTed area.
  1594.  
  1595.  
  1596.  
  1597.  
  1598. >>> TRIM() with LIST or DISPLAY
  1599.  
  1600.      Due to the introduction of headings for LIST and DISPLAY, the
  1601. TRIM() function may not work as you expect when used with these
  1602. commands.  Specifically, if you LIST or DISPLAY a list of TRIMmed
  1603. fields, they will not be TRIMmed.  Use an expression that includes the
  1604. TRIM function instead.  For example:
  1605.  
  1606. LIST TRIM( Firstname ), Lastname
  1607.  
  1608. will not work, but the following will:
  1609.  
  1610. LIST TRIM( Firstname ) + ' ' + Lastname
  1611.  
  1612.  
  1613. >>> VAL() function
  1614.  
  1615.      (1) In version 1.1, SET DECIMALS affects the VAL() function.  Page
  1616. 4-110 of the dBASE III User Manual states that SET DECIMALS applies
  1617. only to division, SQRT(), LOG(), and EXP().  Page 5-39 says that the
  1618. VAL() function does not display the decimal portion of a number.
  1619. However, how the output of the VAL() is displayed will correspond to
  1620. the number of decimal positions defined with the SET DECIMALS command.
  1621. For example:
  1622.  
  1623. SET DECIMALS TO
  1624. x = "1.1111"
  1625. ? VAL( x )
  1626. 1
  1627. SET DECIMALS TO 2
  1628. ? VAL( x )
  1629. 1.11
  1630. SET DECIMALS TO 10
  1631. ? VAL( x )
  1632. 1.1111000000
  1633.  
  1634.      (2) Using any non-numeric argument with the VAL() function will
  1635. return 0.00.  For example:
  1636.  
  1637. ? VAL("Truth")
  1638.   0.00
  1639.  
  1640. However, if an asterisk is used as the argument of the VAL() function,
  1641. it will return "****".
  1642.  
  1643. ? VAL("*")
  1644.   ****
  1645.  
  1646.      In dBASE III, the asterisk is used in this way to signal that an
  1647. operation resulted in a numeric overflow.  If the VAL() function did
  1648. not return asterisks, some operations might obscure the fact that a
  1649. numeric overflow occurred.  For example:
  1650.  
  1651.  
  1652.  
  1653. divisor = 0
  1654. dividend = 1
  1655. x = dividend/divisor
  1656. ? x
  1657. **************
  1658. y = STR(x,1)
  1659. ? y
  1660. *
  1661. z = VAL(y)
  1662. ? z
  1663. ****
  1664.  
  1665. If the VAL() function above returned 0, the quotient might have been
  1666. misinterpreted as being 0.
  1667.  
  1668.      (3) In converting from a character expression to a numeric value,
  1669. the VAL() function evaluates the text from left to right until a
  1670. non-numeric character is encountered.  Leading blanks are ignored.  If
  1671. the function argument contains a mixture of number and text characters,
  1672. only the leading numeric characters will be converted to a numeric
  1673. value.  For example:
  1674.  
  1675. ? VAL( "12ABC" )
  1676.   12.00
  1677.  
  1678. Trailing blanks are treated as non-numeric characters and, when
  1679. encountered, the conversion process is terminated.  For example:
  1680.  
  1681. ? VAL( "12   12" )
  1682.   12.00
  1683.  
  1684.  
  1685. >>> Warning against using a dBASE III file in dBASE II
  1686.  
  1687.      Whenever dBASE II attempts to read a database file, it writes a
  1688. hexadecimal two (02H) to the first byte of the file.  Therefore,
  1689. attempting to USE a dBASE III file in dBASE II will make the file
  1690. unusable by dBASE III.  Any attempt to USE the corrupted file in dBASE
  1691. III will give the error message "Not a dBASE database."
  1692.  
  1693.  
  1694.                              Menu 9
  1695.  
  1696. INDEX OF dBASE III REFERENCE TOPICS
  1697.  
  1698. Menu
  1699. Choice  Topic
  1700. ------  --------------------
  1701.  
  1702.   1    @...GET...RANGE
  1703.        @...GET and READ
  1704.        @...GET...PICTURE
  1705.        @...SAY...PICTURE
  1706.        @...SAY using relative addressing
  1707.        APPEND FROM <filename> [SDF/DELIMITED [WITH <delimiter>]]
  1708.  
  1709.   2    Closing Database Files
  1710.        COPY TO <filename> [SDF/DELIMITED [WITH <delimiter>]]
  1711.        COPY FILE <source filename> TO <target filename>
  1712.        COPY STRUCTURE EXTENDED / CREATE FROM
  1713.        CREATE / MODIFY REPORT
  1714.        Date conversion from dBASE II
  1715.        Dates that are blank
  1716.        Debugging tip
  1717.        Demonstration Disk (RunTime+)
  1718.        DISPLAY and LIST
  1719.        Duplicate Keywords in CONFIG.DB
  1720.        FILE() function
  1721.  
  1722.   3    FIND / SEEK
  1723.        Function Keys
  1724.        Get Diskspace
  1725.        Get Current Directory
  1726.        Get Last Update Date and Time
  1727.        INPUT
  1728.        Macro (&) Substitution in a Format (.FMT) File
  1729.        MEMO fields
  1730.        MODIFY STRUCTURE
  1731.  
  1732.   4    Numeric fields with decimal places
  1733.        Numeric input of large numbers
  1734.        PARAMETERS, passing Fields
  1735.  
  1736.   5    PRIVATE
  1737.        PROCEDURE
  1738.        PROW()
  1739.  
  1740.   6    PUBLIC
  1741.        Ramdisks
  1742.        RELEASE, incorrect syntax
  1743.        RELEASE ALL / CLEAR MEMORY
  1744.        REPLACE
  1745.        REPORT FORM--Dates
  1746.        REPORT FORM HEADING
  1747.        REPORT FORM / MODIFY REPORT
  1748.        REPORT FORM <filename> PLAIN
  1749.  
  1750.   7    Reserved Device Names in MS-DOS
  1751.        Reserved words
  1752.        ROW() / COL()
  1753.        RUN (or !)
  1754.        RUN COMMAND
  1755.        SET ALTERNATE TO
  1756.        SET COLOR
  1757.        SET COLOR TO on the Compaq computer
  1758.        SET CONSOLE ON/OFF
  1759.        SET DEBUG ON
  1760.        SET DELETED
  1761.        SET DOHISTORY (Developer's Release)
  1762.        SET FILTER TO
  1763.        SET MENUS ON/OFF
  1764.        SET PROCEDURE TO / PARAMETERS, PROCEDURE
  1765.  
  1766.   8    SET RELATION TO <expression> INTO <alias>
  1767.        SET RELATION TO
  1768.        SET UNIQUE ON/OFF
  1769.        TRIM with LIST or DISPLAY
  1770.        VAL() function
  1771.        Warning against using a dBASE III file in dBASE II
  1772.  
  1773.   9    This Index.
  1774.  
  1775.  10    CONFIG.SYS
  1776.        dCONVERT
  1777.        File Control Blocks
  1778.        Hard Disk Usage
  1779.        Installing version 1.0
  1780.        Prolok (version 1.0)
  1781.  
  1782.  
  1783.                              Menu 10
  1784. >>> CONFIG.SYS
  1785.  
  1786.      (1) The DOS configuration file, Config.sys, which contains
  1787. FILES=20, must be in the root directory of the disk that DOS is either
  1788. cold or warm booted from. The consequence of its absence when operating
  1789. dBASE III is the unexpected error message "Too many files are open".
  1790. To correct this problem:
  1791.  
  1792.      (a) Go to the root directory of the disk that DOS is booted from;
  1793.      (b) Create a Config.sys by entering the following at the system
  1794. prompt:
  1795.  
  1796. A>copy con: config.sys <RETURN>
  1797. BUFFERS=15 <RETURN>
  1798. FILES=20 <RETURN>
  1799. Ctrl-Z <RETURN>
  1800.  
  1801.      (c) Reboot DOS by pressing Ctrl-Alt-Del.
  1802.  
  1803.      (2) Adding buffers and files with Config.sys is not free of memory
  1804. overhead.  Each buffer uses 528 bytes and each file uses approximately
  1805. 39 bytes.  In addition, hard disks such as Davong and Corvus use large
  1806. amounts of memory.  With BUFFERS and FILES set high, and a hard disk,
  1807. some 256K systems may not have enough room to run dBASE III.  Reducing
  1808. these parameters to a lower amount (such as FILES=15 and BUFFERS=2) may
  1809. be the only way to run dBASE III on these systems.
  1810.  
  1811.  
  1812. >>> dCONVERT
  1813.  
  1814.      (1) dCONVERT, version 1.0 has an option for converting dBASE III
  1815. files to dBASE II format.  When this is chosen the first byte of the
  1816. file is changed from 03 to 02 and other changes are made to the header,
  1817. but a dBASE II format header is not created.  The result is a file
  1818. unusable by dBASE II or dBASE III.  To work around this problem, COPY
  1819. the dBASE III file to a text file using the SDF option.  CREATE a file
  1820. in dBASE II with the same structure and APPEND the text file using the
  1821. SDF option.
  1822.  
  1823.      (2) dCONVERT will not convert command files that use four-letter
  1824. abbreviations of dBASE II commands, such as DISP and ERAS.
  1825.  
  1826.      (3) Some 1-2-3 users have found that dCONVERT will not convert the
  1827. dBASE II database files that 1-2-3's Translate utility generates.
  1828. Apparently Translate creates a database file that is not an exact
  1829. dBASE II database file.  To work around this problem, create an ASCII
  1830. text file from your 1-2-3 worksheet by using the following procedure:
  1831.  
  1832. In Lotus 1-2-3:
  1833.   (1) Setup a worksheet to print without headers and footers with
  1834.       / P rint  F ile  O ther  U nformatted;
  1835.   (2) Make the top, bottom, and left margins zero;
  1836.   (3) Write the text file with / P rint  F ile;
  1837.  
  1838. In dBASE III:
  1839.   (1) CREATE a database that reflects the structure of the 1-2-3
  1840.       worksheet;
  1841.   (2) Read the text file into dBASE III with APPEND FROM <worksheet
  1842.       name>.prn SDF.
  1843.  
  1844.  
  1845. >>> FILE CONTROL BLOCKS
  1846.  
  1847.      dBASE III was designed to use the XENIX type "ASCII I/O handles"
  1848. when setting up FCB's (File Control Blocks) for its I/O.  Whenever
  1849. dBASE III opens a file, DOS provides a control block.  However, DOS
  1850. only has space for 20 such blocks (FILES = 20).  Since DOS uses five
  1851. of these files, fifteen are left for dBASE III.
  1852.  
  1853.  
  1854. >>> HARD DISK USAGE
  1855.  
  1856.      Customers using dBASE III with a hard disk system who wish to use
  1857. an external editor for MODIFY COMMAND or memo field when editing will
  1858. find that DOS checks the A: drive for COMMAND.COM whenever it loads the
  1859. external editor if A: is the boot drive. This can be avoided by setting
  1860. up the DOS environment to look for COMMAND.COM on the default drive
  1861. (hard disk) and subdirectory.  The command to do this is:
  1862.  
  1863. SET COMSPEC=DRIVE\PATH\COMMAND.COM
  1864.  
  1865. This can be entered at the system prompt or placed in an AUTOEXEC.BAT
  1866. file.  For example, if dBASE III were on drive C: in a subdirectory
  1867. called DBASE, the command would be:
  1868.  
  1869. SET COMSPEC=C:\DBASE\COMMAND.COM
  1870.  
  1871.  
  1872.  
  1873. You must of course have COMMAND.COM present in this subdirectory.  If
  1874. the SET command is included in an AUTOEXEC.BAT file, "SET COMSPEC="
  1875. without any parameters must be included before the new command in order
  1876. to clear the default setting. The status of this command can be checked
  1877. by entering "SET" at the system prompt.
  1878.  
  1879.  
  1880. >>> INSTALLING dBASE III  (version 1.0)
  1881.  
  1882.      The errata sheet (dated June 18, 1984) that was shipped with the
  1883. first several thousand copies of dBASE III explains a method for making
  1884. the original system disk bootable using the SYS command. Unfortunately,
  1885. this will not work.  Since the directory space for the system was not
  1886. reserved, the message, "No room for system on destination disk,"
  1887. results when SYS is run.  In order to make bootable copies of dBASE III
  1888. the following procedur must be followed:
  1889.  
  1890.      1. Format two disks and place the operating system on them with
  1891. the FORMAT d:/S command.
  1892.      2. Copy DBASE.EXE and CONFIG.SYS onto one of the newly formatted
  1893. disks.
  1894.      3. Copy DBASE.OVL, CONFIG.DB, HELP.DBS, and ASSIST.HLP to the
  1895. other new disk.
  1896.      4. To boot dBASE III, place the copy of DBASE.EXE (disk from step
  1897. 2. above) in drive A:, the original master system disk in drive B:,
  1898. start the computer, and enter:
  1899.  
  1900. DBASE <RETURN>
  1901.  
  1902. The message "Insert dBASE III overlay file diskette, or type Ctrl-C to
  1903. abort" will appear.
  1904.  
  1905.     5. Remove the copy from drive A: and the master disk from drive B:.
  1906. Place the disk with the copy of the overlay file (from step 3.) in
  1907. drive A: and strike any key.
  1908.     6. Place the master system disk in a safe place.  It will not be
  1909. needed until dBASE III is started again.  Drive B: is free for whatever
  1910. programs or data files you wish to work with.
  1911.  
  1912.  
  1913. >>> PROLOK (version 1.0)
  1914.  
  1915.     (1) Each system disk that contains dBASE III is copy protected with
  1916. the Prolok copy protection scheme.  Every time dBASE III is loaded,
  1917. Prolok which is internal to dBASE looks for the disk that has the
  1918. Prolok identification on it before passing control to the dBASE loading
  1919. routine.  If the presence of the identifying disk is not sensed, the
  1920. message "Unauthorized Duplicate" is displayed and the loading of dBASE
  1921. is terminated.  What must not be overlooked is that each copy of dBASE
  1922. III is uniquely identified with the system disk that it came from, much
  1923. as child to a parent.  This is of particular importance to hard disk
  1924. users who copy dBASE III to, and boot from the hard disk. Users booting
  1925. from the hard disk will often attempt to use as the identifying disk a
  1926. system disk that the dBASE on the hard disk cannot identify as its
  1927. parent resulting in "Unauthorized Duplicate".
  1928.  
  1929.     (2) The Prolok procedure is designed to physically damage the disk.
  1930. Therefore, running CHKDSK on it will report bad sectors -- 10240 bytes
  1931. in bad sectors, to be exact.
  1932.  
  1933.