home *** CD-ROM | disk | FTP | other *** search
/ Shareware Overload / ShartewareOverload.cdr / database / db3work.zip / DB3WORK.TXT
Text File  |  1986-03-28  |  53KB  |  1,578 lines
  1. - Locating dBASE III Usage Tips -
  2.  
  3. ( from the Source  - Ashton Tate SIG-  ATSIG )
  4.  
  5. 63 item(s) found for  ALL
  6.  
  7. title:  ASCII VALUES RETURNED IN RESPONSE TO WAIT
  8. version:  DR
  9. date:  10 Mar 1986
  10. text: 
  11. The ASCII codes stored in response to the WAIT command are
  12. different in the Developer's Release of dBASE III than in
  13. versions 1.0 and 1.1.  The code values returned from function
  14. keys in the Developer's Release are larger by one.  The
  15. following table shows the codes returned from each version.
  16.  
  17.                 Developer's     Versions
  18. Key          Release      1.0 and 1.1  Function
  19. ===        ===========    ===========  ========
  20. F1             0              0        HELP
  21. F2            255            254       ASSIST
  22. F3            254            253       LIST
  23. F4            253            252       DIR
  24. F5            252            251       DISP STRU
  25. F6            251            250       DISP STAT
  26. F7            250            249       DISP MEMO
  27. F8            249            248       DISPLAY
  28. F9            248            247       APPEND
  29. F10           247            246       EDIT
  30. SPACE          32             32       SPACE
  31. BACKSPACE     127            127
  32.  
  33.  
  34. All other keys that send non-display characters including
  35. Alt, Ctrl, and shifted keypad characters, return an ASCII 0.
  36.  
  37.  
  38. title:  SET ORDER TO WITH RECORD POINTER NEAR BOTTOM OF FILE
  39. version:  DR
  40. date:  10 Mar 1986
  41. text: 
  42. SETting ORDER TO will take an inordinate amount of time to
  43. execute if the record pointer is at or near the bottom of the
  44. database file.  SET ORDER TO takes six to ten times longer than
  45. to SET INDEX TO the same order and restore the record pointer
  46. to its previous position.
  47.  
  48.  
  49. title:  SET HISTORY TO NON-NUMERIC
  50. version:  DR
  51. date:  10 Mar 1986
  52. text: 
  53. SET HISTORY TO accepts only numeric chararcters reading from
  54. left to right until a nonnumeric character is encountered.
  55. Therefore, the commands:
  56.  
  57. SET HISTORY TO 1,000,000
  58. SET HISTORY TO 1.9
  59.  
  60. are functionally identical to:
  61.  
  62. SET HISTORY TO 1
  63.  
  64.  
  65. title:  LINE LENGTH LIMIT FOR HISTORY
  66. version:  date:  10 Mar 1986
  67. text: 
  68. The maximum command line length in dBASE III is 254
  69. characters.  HISTORY reserves 240 characters (three lines of
  70. the screen) for each command line.  Commands longer than 240
  71. characters are truncated when recorded in HISTORY.  This occurs
  72. whether the command is recorded through SET HISTORY ON or SET
  73. DOHISTORY ON.
  74.  
  75.  
  76. title:  CTOD() WITH INVALID STRING ARGUMENT
  77. version:  10 11
  78. date:  10 Mar 1986
  79. text: 
  80. The CTOD() function will accept any string as an argument and
  81. return a date.  If the string is not a valid date string within
  82. the format of SET DATE, the results of the CTOD() function will
  83. be unpredictable.
  84.  
  85. The CTOD() function converts any literal that contains only
  86. nonnumeric characters to 11/30/99.  For example:
  87.  
  88.  ? CTOD('HALLOWEEN')
  89.    11/30/99
  90.  
  91. The CTOD() function converts strings containing numeric and
  92. nonnumeric characters not in the format selected with SET DATE
  93. to a date without producing an error message.  For example:
  94.  
  95.  ? CTOD(`12//12')
  96.  11/30/12
  97.  ? CTOD('he12/12')
  98.  11/30/11
  99.  ? CTOD('12/12/he')
  100.  12/12/00
  101.  
  102. The Developer's Release of dBASE III, however, returns a blank
  103. date if the CTOD() function is used with an incorrect value.
  104.  
  105.  
  106. title:  BLANK IF ZERO
  107. version:  10 11 DR
  108. date:  10 Mar 1986
  109. text: 
  110. Sometimes you may wish to display a blank instead of a zero for
  111. an empty numeric variable.  If you are using an @..SAY command
  112. to display the numeric variable, use the @Z function of the
  113. PICTURE clause.  For example,
  114.  
  115. number = 0
  116. @ 10,10 SAY number PICTURE "@Z 999"
  117.  
  118. If however, you are displaying the numeric variable with a
  119. non-full screen command such as LIST, ?, or the REPORT FORM,
  120. you will have to use an expression to suppress the zero
  121. display.  To replace a zero field value with a blank, first
  122. change the field contents to a character string using the STR()
  123. function.  Then use the SUBSTR() and AT() functions to replace
  124. the zero string with a blank string.
  125.  
  126. The following expression can be used to accomplish this:
  127.  
  128.    SUBSTR(SPACE(5)+STR(Numfield,5,2),AT(STR(Numfield,5,2),
  129.      ' 0.00'+STR(Numfield,5,2)),5)
  130.           ^                     ^-------- This value and the value
  131.           |                               of SPACE() must
  132. equal
  133.           |                               the length of the field.
  134.           |
  135.  
  136.            ------------------------------ The length of this
  137. clause
  138.                                         must also be the length
  139.                                           of the field.
  140.  
  141. If you have the Developer's Release, use the TRANSFORM()
  142. function and the @Z function of the PICTURE clause as you would
  143. with the @..SAY..PICTURE command.  For example,
  144.  
  145. number = 0
  146. ? TRANSFORM( number, "@Z 999" )
  147.  
  148.  
  149. title:  FORMAT FILE MUST NOT BE ENCRYPTED
  150. version:  DR
  151. date:  10 Mar 1986
  152. text: 
  153. A format file must remain unencrypted, or be worked into the
  154. .SRC file to be utilized by dBRUN.  The documentation for
  155. RunTime+ does not mention that an unencrypted format (.FMT)
  156. file may be accessed with the SET FORMAT TO command.  In fact,
  157. dBRUN will process only an unencrypted format file with this
  158. command.
  159.  
  160.  
  161. title:  ON KEY DOES NOT INTERRUPT COMMAND BEING PROCESSED
  162. version:  DR
  163. date:  10 Mar 1986
  164. text: 
  165. If you have set the ON KEY command and are executing any
  166. command that takes some time to process, such as LIST or REPORT
  167. FORM, pressing a key will not interrupt the command being
  168. executed.  Instead the key pressed will be stored in the
  169. typeahead buffer and ON KEY will execute when that command is
  170. finished.
  171.  
  172.  
  173. title:  POSSIBLE TO SET RANGE FROM UPPER TO LOWER LIMIT
  174. version:  10 11 DR
  175. date:  10 Mar 1986
  176. text: 
  177. It is possible to set a RANGE from the upper limit to the lower
  178. limit rather than from the lower limit to the upper.  For
  179. example:
  180.  
  181. mem = 0
  182. @ 2,2 GET mem PICTURE "9" RANGE 9,1
  183.  
  184. Although this is not trapped as an error, no entry can
  185. meet this RANGE specification.  Placing the higher value
  186. as the first argument creates an impossible condition by
  187. requiring that the entry be both greater than or equal to
  188. the upper limit and less than or equal to the lower
  189. limit.
  190.  
  191.  
  192. title:  LOCATE WHILE
  193. version:  10 11
  194. date:  10 Mar 1986
  195. text: 
  196. Page 4-73 of the dBASE III Reference Manual for version 1.1
  197.                  __________________________
  198. gives the syntax of the LOCATE command as:
  199.  
  200. LOCATE [<scope>] FOR/WHILE <condition>
  201.  
  202. However, the WHILE clause of the LOCATE command is not
  203. implemented in versions of dBASE III earlier than the
  204. Developer's Release.  Use of the command:
  205.  
  206. LOCATE WHILE <condition>
  207.  
  208. will produce "Syntax error."  Attempting to use the FOR and
  209. WHILE clauses together will give, "FOR and WHILE cannot both be
  210. specified."
  211.  
  212. In the Developer's Release the WHILE clause is fully
  213. implemented, incling the simultaneous use of the FOR and WHILE
  214. clauses.
  215.  
  216.  
  217.  
  218. title:  BLANK LINES IN LABEL FORM
  219. version:  10 11 DR
  220. date:  10 Mar 1986
  221. text: 
  222. If you are defining a formatted LABEL FORM, you may want to
  223. include blank lines for spacing.  The LABEL FORM, however,
  224. suppresses all blank lines whether you have defined an
  225. expression whose contents are blank or whether the line in your
  226. definition is blank.  To create a blank line, enter into the
  227. line contents area the expression CHR( 255 ).  This will cause
  228.  
  229.  
  230. the LABEL FORM to recognize the line as nonblank and print the
  231. ASCII character represented by CHR( 255 ), which has no display
  232. value.
  233.  
  234.  
  235. title:  FIND AND SEEK WILL BOTH PERFORM CONCATINATION
  236. version:  10 11 DR
  237. date:  10 Mar 1986
  238. text: 
  239. The FIND command performs string concatenations, although it is
  240. not documented as having this capability.  For example:
  241.  
  242. FIND 'P'+'A'
  243.  
  244. will find "PA."
  245.  
  246. FINDing on a numeric key will FIND an expression up to a
  247. special character.  The following examples of the FIND command
  248. will all FIND the record with "755" in the key.
  249.  
  250. FIND 755 / 3
  251. FIND 755 * 3
  252. FIND 755 - 3
  253.  
  254.  
  255. title:  FIND WILL IGNORE LEADING SPACES WHEN FINDING A LITERAL
  256. version:  10 11 DR
  257. date:  10 Mar 1986
  258. text: 
  259. The FIND command will ignore leading
  260. blanks when searching a literal
  261. string.  The results of the commands,
  262.  
  263. FIND A
  264. FIND        A
  265.  
  266. are identical.  For this reason the commands,
  267.  
  268. FIND &memvar
  269. FIND "&memvar"
  270.  
  271. are not interchangeable when the string being sought has
  272. leading blanks.  For example:
  273.  
  274. STORE " A" TO memvar
  275. FIND &memvar        <-- will find "A"
  276. FIND "&memvar"      <-- will find " A"
  277.  
  278.  
  279. title:  LAST UPDATE DATE AND TIME
  280. version:  10 11 DR
  281. date:  10 Mar 1986
  282. text: 
  283. To get the date of last update for the currently SELECTed
  284. database file in the Developer's Release of dBASE III, use the
  285. LUPDATE() function.  LUPDATE() returns the date of last update
  286. as a value of date type.
  287.  dBASE III versions 1.0 and 1.1 currently do not have a
  288. function that returns the date of last update for the SELECTed
  289. database file.  To get the date of last update in these
  290. versions of dBASE III, use the PC/MS-DOS command DIR, and
  291. import the results into dBASE III.  The basic algorithm is as
  292. follows:
  293.  
  294. 1. Create or have available a general purpose database
  295.    file called Util.DBF.  Util.DBF has one field called
  296.    Util_line which is character type and has a length of
  297.    80.
  298.  
  299. 2. RUN the PC/MS-DOS command DIR with the name of your
  300.    database file, piping the result into a text file
  301.    entitled Util.TXT.
  302.  
  303. 3. APPEND the text file Util.TXT into the database file
  304.    Util.DBF.
  305.  
  306. 4. Assign to a memory variable the date of last update
  307.    from Util.DBF for your database file.
  308.  
  309. The code that will get the last update of the currently
  310. SELECTed database file is as follows:
  311.  
  312.    SET SAFETY OFF
  313.    RUN DIR <Yourfile>.DBF > Util.TXT
  314.    USE Util
  315.    ZAP
  316.    APPEND FROM Util SDF
  317.    lupdate = SUBSTR( Util_line, 25, 8 )
  318.    luptime = SUBSTR( Util_line, 34, 6 )
  319.    USE
  320.    SET SAFETY ON
  321.    RETURN
  322.  
  323.  
  324. title:  GET CURRENT DIRECTORY
  325. version:  10 11 DR
  326. date:  10 Mar 1986
  327. text: 
  328. dBASE III has no facility to get the name of the current
  329. directory.  To get it you must RUN the PC/MS-DOS command CD and
  330. import the results into dBASE III.  The basic algorithm is as
  331. follows:
  332.  
  333. 1. Create or have available a general-purpose database
  334.    file called Util.DBF.  Util.DBF has one field called
  335.    Util_line which is character type and has a length of
  336.    80.
  337.  
  338. 2. RUN the PC/MS-DOS command CD, piping the result into a
  339.    text file entitled Util.TXT.
  340.  
  341. 3. APPEND the text file Util.TXT into the database file,
  342.    Util.DBF.
  343.  
  344. 4. Assign to a memory variable the name of the current DOS
  345.    directory from Util.DBF.
  346.  
  347.  The code that will execute this algorithm is as follows:
  348.  
  349.    SET SAFETY OFF
  350.    RUN CD > Util.TXT
  351.    USE Util
  352.    ZAP
  353.    APPEND FROM Util SDF
  354.    currdir = TRIM( Util_line )
  355.    SET SAFETY ON
  356.    RETURN
  357.  
  358.  
  359. title:  GET DISKSPACE
  360. version:  10 11 DR
  361. date:  10 Mar 1986
  362. text: 
  363. In the Developer's Release use the DISKSPACE() function to get
  364. the amount of space left on the currently logged drive.  The
  365. DISKSPACE() will return the number of free bytes on the default
  366. drive as a numeric value .
  367.  dBASE III versions 1.0 and 1.1 do not have a function to
  368. return the amount of space left on the default drive.  So, to
  369. get the amount of diskspace in these versions, use the
  370. PC/MS-DOS utility CHKDSK and import the results into dBASE
  371. III.  The basic algorithm is as follows:
  372.  
  373. 1. Create or have available a general purpose database file
  374. called Util.DBF.  Util.DBF has one field called Util_line which
  375. is character type and has a length of 80.  This database file
  376. will be useful for any of these kinds of survey operations into
  377. PC/MS-DOS.
  378.  
  379. 2. RUN CHKDSK including the designator of the drive for which
  380. you want the space statistic for, and pipe the result into a
  381. text file entitled Util.TXT.  Piping is a PC/MS-DOS capability
  382. that allows the results of a program to be sent into a text
  383. file.  It is very useful for passing parameters between
  384. programs when there is no formalized interface.  The syntax is:
  385.  
  386.           <DOS commmand>  >  <result text file>
  387.  
  388.                           _____ DOS piping symbol
  389.  
  390.    For more information on this capability, consult your
  391. PC/MS-DOS reference manual.
  392.  
  393. 3. APPEND the text file, Util.TXT, into the database file,
  394. Util.DBF.
  395.  
  396. 4. Assign to a memory variable the number of free bytes on the
  397. specified drive from Util.DBF.  This operation requires that
  398. you GOTO the record that contains the free disk space
  399. information and then extract the number of bytes from the field
  400. using the SUBSTR() function.
  401.  
  402.    The following is a LIST of Util.DBF with the results of a
  403. CHKDSK reporG    ;hen APPENDed into a {xbase file, the first
  404. and last records are always blank. Records 2 through 6 contain
  405. statistics about the currently logged disk drive.  Note that
  406. this is the currently logged DOS drive and not the DEFAULT
  407. drive SET in dBASE III.  Records 8 and 9 contain statistics
  408. about the memory configuration of your computer.  The number of
  409. bytes for each attribute of the drive and memory occupy
  410. positions 1 through 9 in the database field, Util_line.
  411.  
  412.    Record#
  413.          1
  414.          2    9965568 bytes total disk space
  415.          3     155648 bytes in 4 hidden files
  416.          4      90112 bytes in 22 directories
  417.          5    6000640 bytes in 397 user files
  418.          6    3719168 bytes available on disk
  419.          7
  420.          8     524288 bytes total memory
  421.          9     122480 bytes free
  422.         10
  423.  
  424. The code that will get the the number of free bytes on the
  425. specified disk drive is as follows:
  426.  
  427.    SET SAFETY OFF
  428.    RUN CHKDSK > Util.TXT
  429.    USE Util
  430.    ZAP
  431.    APPEND FROM Util SDF
  432.    GO 6
  433.    diskspace = STR( SUBSTR( Util_line, 1, 9 ), 9 )
  434.    USE
  435.    SET SAFETY ON
  436.    RETURN
  437.  
  438.  
  439. title:  FUNCTION KEYS
  440. version:  10 11 DR
  441. date:  10 Mar 1986
  442. text: 
  443. F1 toggles the cursor control menu on and off in the following
  444. full screen edit modes.
  445.  
  446.      APPEND    EDIT      MODIFY LABEL        MODIFY STRUCTURE
  447.      BROWSE    CHANGE    MODITY REPORT
  448.  
  449.  
  450. title:  FIND AND SEEK
  451. version:  10 11 DR
  452. date:  10 Mar 1986
  453. text: 
  454. FIND and SEEK are both used to move the record pointer of an
  455. indexed database to the first instance of the index key that
  456. matches the search argument.  FIND searches on a literal
  457. character string while SEEK searches on an expression the value
  458. of which may be character, date, or numeric.
  459.  
  460. The proper choice of command is related to the context and data
  461. type of the index key.  Generally, FIND will only be used to
  462. search for a literal character string and SEEK for all other
  463. searches. The following are some typical cases:
  464.  
  465.  (1) You have an index key that is character and are
  466.      working from the dot prompt:
  467.            . FIND Lee
  468.     {or}   . SEEK "Lee"
  469.  
  470.  (2) You have an index key that is numeric or date and
  471.      are working from the dot prompt:
  472.            . SEEK 1250
  473.            . SEEK CTOD('12/12/85')
  474.  
  475.  (3) You are working within a command file and are
  476.      initializing a memory variable as a search key:
  477.            STORE SPACE(10) TO skey
  478.            @ 10,10 SAY 'Enter value to search for' GET skey
  479.            READ
  480.            SEEK skey
  481.  
  482.  (4) You have a database field that is character, Code, and
  483.      the contents are numeric digits and right-justified:
  484.            ACCEPT 'Enter code to search for' to skey
  485.            SEEK SPACE(LEN(Code) - LEN(skey)) + skey
  486.  
  487.  (5) You are working with several databases and want to
  488.      search for a key value in the current work area using a
  489.      field variable from a non-active area with an alias
  490.      name:
  491.                SELECT 1
  492.                USE File1 INDEX File1
  493.                SELECT 2
  494.                USE File2 INDEX File2
  495.                SELECT File1
  496.                SEEK File2->Field1
  497.  
  498.  
  499. title:  SET COLOR
  500. version:  10 11
  501. date:  10 Mar 1986
  502. text: 
  503. (1) To get enhanced video to be black on black, use the command SET
  504. COLOR TO x/y,0+/0.  Black on black is frequently used to allow user
  505. input without displaying the characters on the screen, as with entry
  506. of a password.
  507.  
  508. (2) The command:
  509.  
  510.     SET COLOR TO  ,<cr>
  511.  
  512. will produce black on black, even if there is no space
  513. after the comma.
  514.  
  515. (3) The asterisk (*) used with the SET COLOR command allows you to
  516. have blinking characters on the screen.  The asterisk must be used in
  517. conjunction with a color parameter.  For example:
  518.  
  519.      SET COLOR TO 6*/1,7/4,6
  520.  
  521.  or:
  522.  
  523.      SET COLOR TO GR*/B,W/R,GR
  524.  
  525.  
  526. title:  SET ALTERNATE TO
  527. version:  10 11
  528. date:  10 Mar 1986
  529. text: 
  530. dBASE III will not send a linefeed (that is, CHR(10)) to an
  531. alternate file (Word Perfect looks for this linefeed character in
  532. its mail merge program).  The following command file:
  533.  
  534.      SET ALTERNATE TO x
  535.      SET ALTERNATE ON
  536.      ?? "first LF"
  537.      ?? CHR(10)
  538.      ?? "second LF"
  539.      SET ALTERNATE OFF
  540.      CLOSE ALTERNATE
  541.  
  542.  will generate the following test file:
  543.  
  544.      first LFsecond LF
  545.  
  546. As you can see, there is no linefeed in the file.
  547.  
  548.  
  549. title:  RUN COMMAND
  550. version:  10 11 DR
  551. date:  10 Mar 1986
  552. text: 
  553. You can get the equivalent to Framework's DOS Access in dBASE III
  554. by issuing RUN COMMAND.  This will leave you at the DOS operating
  555. system level and will allow you to enter any DOS commands.  To
  556. get back to the dBASE III dot prompt, type EXIT.
  557.  
  558.  
  559. title:  RUN (OR !)
  560. version:  10 11 DR
  561. date:  10 Mar 1986
  562. text: 
  563. The RUN command requires that COMMAND.COM be in the boot drive or
  564. the directory indicated by SET COMSPEC.  Otherwise, the incorrect
  565. error message "Insufficient memory" is displayed.
  566.  
  567.  
  568. title:  ROW(), COL()
  569. version:  10 11 DR
  570. date:  10 Mar 1986
  571. text: 
  572. After a READ, the ROW() function always returns 24; however, the
  573. COL() function does not change.  For example:
  574.  
  575.      SET TALK OFF
  576.      var = SPACE(2)
  577.      @ 5,40 GET var
  578.      ? ROW(), COL()      <--- This returns 6 and 3.
  579.      READ
  580.      ? ROW(), COL()      <--- This returns 24 and 3.
  581.  
  582.  
  583. title:  RESERVED WORDS
  584. version:  10 11 DR
  585. date:  10 Mar 1986
  586. text: 
  587. Page 1-138 of the tutorial in the first edition of the manual
  588. uses a sample routine which creates a memory variable with the
  589. name 'continue.' Since this is a reserved word, dBASE III will
  590. give the message, "No database in USE, enter filename."  dBASE
  591. III is assuming you intend to CONTINUE on a LOCATE command.
  592. This will only happen if you use the <variable> = <value> form of
  593. assignment; dBASE III will execute correctly when you use the
  594. STORE <value> TO <variable> form.  Other words that will not work
  595. with the first syntax are: AVERAGE, COUNT, and SUM.
  596.  
  597. title:  RESERVED DEVICE NAMES IN MS-DOS
  598. version:  10 11 DR
  599. date:  10 Mar 1986
  600. text: 
  601. The MS-DOS manual specifies that certain names have a special meaning
  602. to MS-DOS.  Do not use these reserved device names as dBASE III
  603. filenames: CON, AUX, COM1, COM2, LPT1, PRN, LPT2, LPT3, or NUL.  This
  604. applies to database files, index files, command files, format files,
  605. or form files.  Various error messages will result when files with any
  606. of these names are accessed.
  607.  
  608.  
  609. title:  REPORT FORM
  610. version:  10 11
  611. date:  10 Mar 1986
  612. text: 
  613. The semicolon is not documented as functioning as a Carriage
  614. Return/Line-Feed in certain parts of REPORT FORMs.
  615.  
  616.  
  617. title:  RANGE
  618. version:  10 11 DR
  619. date:  10 Mar 1986
  620. text: 
  621. The dBASE III Reference Manual states that RANGE may be used to
  622. specify lower and upper bounds for date variables, but does not
  623. clarify that the arguments of the RANGE clause involving literal
  624. dates must be in the form, CTOD("mm/dd/yy").
  625.  
  626.  For example:
  627.  
  628.     @ 10,10 GET Mdate RANGE CTOD("01/01/85"), CTOD("01/01/86")
  629.  
  630.  
  631. title:  REPORT FORM <FILENAME> PLAIN
  632. version:  10 11 DR
  633. date:  10 Mar 1986
  634. text: 
  635. The PLAIN option of the REPORT FORM command will cancel out the
  636. HEADING option when these two are used in the same command line.
  637. Therefore, do not use these two options in the same command.  For
  638. example, the following command line will not print the HEADING "Week
  639. of May 6, 1985":
  640.  
  641.  REPORT FORM Wksales PLAIN HEADING "Week of May 6, 1985" TO PRINT
  642.  
  643.  
  644. title:  REPORT FORM, MODIFY REPORT
  645. version:  10 11
  646. date:  10 Mar 1986
  647. text: 
  648. (1) The report generator will right-justify field headings for
  649. numeric fields when the report is run.
  650.  (2) If the PLAIN clause is specified with REPORT FORM TO PRINT,
  651. no page ejects occur.  The report prints through to the end
  652. without page breaks.
  653.  (3) MODIFY REPORT will allow the number of decimal places to be
  654. changed from the default.  If this is done and the report is
  655. run, everything is as expected.  However, if the report is
  656. modified again, the number of decimal places reverts to the
  657. default when the cursor reaches the "# decimal places" field.
  658.  (4) Although not documented in the manual or in the cursor
  659. control menu, Ctrl-N inserts a column in a report being created
  660. or modified.  However, its counterpart (Ctrl-U which deletes a
  661. column) is documented and included in the help menu.
  662.  
  663.  
  664. title:  REPORT FORM HEADING
  665. version:  10 11 DR
  666. date:  10 Mar 1986
  667. text: 
  668. There appears to be some confusion about the use of the HEADING option
  669. to the REPORT FORM command. The argument of the HEADING statement is a
  670. character expression and, therefore, can contain any combination of
  671. memory variables, field variables including aliases, and functions
  672. that evaluate to a value of character type.  This means that macro
  673. substitution is not necessary to in order to use variable data for the
  674. REPORT FORM in question.  As a typical example:
  675.  
  676.      * ---Set up header string.
  677.      title = "Sample Report Number 1"
  678.      *---Run the report.
  679.      REPORT FORM YourRpt HEADING title
  680.  
  681.  If the HEADING argument is a field variable from the database file
  682. being REPORTed on, the value of the HEADING will be the field value
  683. from the record being pointed to when the REPORT FORM is invoked.  For
  684. example, if the current record number is 5 and a REPORT FORM is run
  685. with no scope, the HEADING value is set from record 5 and then the
  686. record pointer is reset to the top of file.
  687.  The ability to use a database field as the HEADING argument presents
  688. some interesting possibilites. Suppose you have a master client and
  689. transaction file. You wish to have a transaction listing for a
  690. particular client with that client's name at the top of the REPORT
  691. FORM. The transactions database file is INDEXed in client number
  692. order.
  693.  
  694.      * ---Open database files.
  695.      SELECT 1
  696.      USE Client
  697.      SELECT 2
  698.      USE Transaction INDEX Transaction
  699.      SELECT Client
  700.      * ---Get the client to report on.
  701.      LOCATE FOR Name = "Smith"
  702.      * ---Report client's transactions.
  703.      SELECT Transaction
  704.      REPORT FORM Transaction HEADING Client->Name;
  705.             WHILE Number = Client->Number
  706.  
  707.  
  708. title:  REPORT FORM--DATES
  709. version:  10 11 DR
  710. date:  10 Mar 1986
  711. text: 
  712. If you have a date-oriented report and you need to have it
  713. grouped by week, the following discussion will assist you.
  714.  The grouping of dates into weeks has two requirements.  First,
  715. the database file you are reporting from must be INDEXed on the
  716. date field that is being grouped on.  Second, as the group
  717. expression in your REPORT FORM, you must have an expression
  718. that returns as its value the first day of the week for each
  719. date field.  The expression is as follows:
  720.  
  721.  
  722.  
  723. title:  REPLACE
  724. version:  10 11 DR
  725. date:  10 Mar 1986
  726. text: 
  727. REPLACE ALL does not replace all records correctly if an index is
  728. in use and the key field is replaced.  Only the first record and
  729. those that logically follow the new value will be replaced.  This
  730. occurs because the index is automatically updated (in-place key
  731. updating) when it is edited.  The record pointer moves to the
  732. record following the new position, not to the record following
  733. the old position.  This can be illustrated in the example given
  734. below (the data file has five records with the field CHARS-C-1,
  735. and is indexed on this field):
  736.  
  737.      . LIST
  738.      Record#  CHARS
  739.            1  a
  740.            2  b
  741.            3  c
  742.            4  i
  743.            5  j
  744.  
  745.      . REPLACE ALL Chars WITH 'd'
  746.            3 records replaced
  747.      . LIST
  748.            2  b
  749.            3  c
  750.            1  d
  751.            4  d
  752.            5  d
  753.  
  754.  The manual warns against block replacements to the key field.
  755. The correct procedure would be to REPLACE with no indexes in use,
  756. open the indexes with SET INDEX TO, and then REINDEX.
  757.  
  758.  
  759. title:  RELEASE ALL, CLEAR MEMORY
  760. version:  10 11 DR
  761. date:  10 Mar 1986
  762. text: 
  763. RELEASE ALL and CLEAR MEMORY are not equivalent commands as the
  764. dBASE III manual states.  CLEAR MEMORY clears all memory
  765. variables, regardless where they were initialized.  RELEASE ALL,
  766. however, will release all memory variables except those declared
  767. PUBLIC or initialized in a nested command file.
  768.  
  769.  
  770. title:  RELEASE, INCORRECT SYNTAX
  771. version:  10 11 DR
  772. date:  10 Mar 1986
  773. text: 
  774. The syntax "RELEASE ALL LIKE <skeleton>,<skeleton>" is incorrect
  775. but will not produce an error message.  The correct syntax is
  776. either RELEASE <memvar list> or RELEASE ALL LIKE <skeleton>.  You
  777. may use wildcard characters in the RELEASE ALL LIKE form of the
  778. command, but dBASE III will ignore any <skeleton> after the first
  779. comma.
  780.  
  781.  
  782. title:  RAMDISKS
  783. version:  10 11 DR
  784. date:  10 Mar 1986
  785. text: 
  786. There are several options for users who wish to use a ramdisk
  787. in combination with dBASE III.
  788.    a) The minimum drive size will have to be in excess  of
  789.       181,000 bytes.  The DBASE.OVL file for  version 1.1
  790.       is 180,736 bytes.  The total amount  of RAM in your
  791.       machine must be more than 440,000  bytes in order
  792.       to do this.  Additionally, if  you are using a
  793.       CONFIG.DB, it must be present  on the drive where
  794.       .OVL resides.
  795.  
  796.    b) Boot dBASE III from the ramdisk by calling for  the
  797.       DBASE.COM from the drive on which it  resides.  For
  798.       example: drive D: is the ramdisk  and the DBASE.COM
  799.       is on the C: drive.
  800.  
  801.              C> D:
  802.              D> C:DBASE
  803.  
  804. 2. It may be a very useful area for procedure or command
  805.    files to be run from, increasing the speed of
  806.    processing.  Prior to entering dBASE III, copy the
  807.    appropriate files to the ramdisk.  Once in dBASE III,
  808.    SET the DEFAULT TO the ramdisk drive and proceed.
  809.  
  810. 3. It is also useful as a small work area to manipulate
  811.    utility and temporary files.  The useage tips on
  812.    getting the current directory or diskspace are good
  813.    examples of where a small ramdisk would be extremely
  814.    useful and time efficient.
  815.  
  816.  
  817. title:  PUBLIC
  818. version:  10 11 DR
  819. date:  10 Mar 1986
  820. text: 
  821. PUBLIC is used to declare memory variables as global and to
  822. prevent their release when control is returned to the dot prompt.
  823.  
  824. PUBLIC variables must be declared prior to being initialized, and
  825. once declared, these variables will be assigned a logical false
  826. value until initialized.  PUBLIC variables can be re-declared as
  827. PUBLIC without losing the values already stored in them.
  828.  
  829. In programming, declaring all variables as PUBLIC in the main
  830. routine would make dBASE III behave similar to dBASE II.
  831. However, there is one difference in dBASE III, PUBLIC variables
  832. can only be released by the CLEAR MEMORY, CLEAR ALL, and RELEASE
  833. <variable list> commands, but not the RELEASE ALL command.
  834.  
  835.  
  836. title:  PROCEDURE
  837. version:  10 11 DR
  838. date:  10 Mar 1986
  839. text: 
  840. Calling Command Files from Procedures within dBASE III
  841.  
  842. To call a command file from a procedure, you must follow a few
  843. rules.
  844.  Rule 1:
  845. The command file cannot have the same name as any of the
  846. procedures in the file even if the extension is included as part
  847. of the filename.  An attempt to do this will cause the
  848. inappropriate error message, "Unrecognized phrase/keyword in
  849. command."  For example:
  850.  
  851.      * Proc_One.PRG
  852.      PROCEDURE One
  853.         * ---The next command will not work because
  854.         * ---Two is a procedure in this file.
  855.         DO Two.PRG
  856.      RETURN
  857.      *
  858.      PROCEDURE Two
  859.         * ---The next command will work.
  860.         DO Three.PRG
  861.      RETURN
  862.      * EOF: Proc_One.PRG
  863.  
  864.  This can be avoided by renaming either the command file or
  865. procedure.  To avoid this problem you might want to begin
  866. procedure names with a prefix that command files will not have.
  867. For instance, in the previous example the procedures could have
  868. been called P_One and P_Two.
  869.  
  870.  Rule 2:
  871.  Once the command file is invoked from a procedure file, it must
  872. not DO another procedure in the procedure file.  Instead, it
  873. should RETURN to the calling procedure.  Otherwise, the called
  874. procedure will usually execute, but an error message will be
  875. displayed for a command line that does not exist.
  876.  
  877.  Rule 3:
  878.  Internal procedure calls (that is, a procedure that calls either
  879. itself or another procedure in the same file) must be kept to
  880. eighteen nested calls or less.  The nineteenth call attempt will
  881. return execution to the calling command file with no error
  882. message.
  883.  
  884.  
  885. title:  PRIVATE
  886. version:  10 11 DR
  887. date:  10 Mar 1986
  888. text: 
  889. In dBASE III, all variables are PRIVATE to the routine in which
  890. they are initialized unless otherwise declared.  Variables
  891. created at the dot prompt will automatically be PUBLIC no matter
  892. how they are declared.
  893.  Declaring a variable PRIVATE in a command file hides any outer-
  894. level definition of a variable with the same name from the
  895. current routine.  It also hides any deeper-level routines from
  896. viewing any outer-level definition of a variable with the same
  897. name.  In the example below, programs B.PRG and C.PRG do not have
  898. access to variable X in program A.PRG.  Program C.PRG, therefore,
  899. will display X with a value of 15 and not 10.  Program A.PRG,
  900. however, will display X with the old value of 10 even after
  901. executing program B.PRG.
  902.  
  903.      * A.PRG
  904.      x = 10
  905.      DO B    ----------> * B.PRG
  906.      ? x                 PRIVATE x
  907.      RETURN              x = 15
  908.                          DO C    ----------> * C.PRG
  909.                          RETURN              ? x
  910.                                              RETURN
  911.  
  912.  In programming, you will want to declare a variable PRIVATE in a
  913. subroutine if you do not want this variable to interfere with an
  914. outer-level variable having the same name.
  915.  
  916.  To illustrate the use of PRIVATE, the command files MAIN.PRG and
  917. SUB.PRG are listed below, with the displayed output.  Notice that
  918. all the variables are released when MAIN.PRG returns control to
  919. the dot prompt.  Also notice that the variables initialized in
  920. MAIN.PRG are PRIVATE in the memory display even though they are
  921. never explicitly declared.  Lastly, notice that the value
  922. assigned to  height  in SUB.PRG  is not  returned to MAIN.PRG, but
  923. the value assigned to  area  in SUB.PRG  is  returned.  This is
  924. because  height  is declared PRIVATE in SUB.PRG and  area  is not.
  925.  
  926.  LISTINGS:
  927.  
  928.      * MAIN.PRG
  929.      * --------
  930.      area = 0
  931.      height = 304
  932.      ? "Before call to SUB:"
  933.      ? "-------------------"
  934.      DISPLAY MEMORY
  935.      DO Sub    ------------------> * SUB.PRG
  936.      ? "After call to SUB:"        * -------
  937.      ? "------------------"        PRIVATE height
  938.      DISPLAY MEMORY                height = 30
  939.      RETURN                        area = 10 * 20 * height
  940.      * EOF: MAIN.PRG               ? "Inside SUB:"
  941.                                    ? "-----------"
  942.                                    DISPLAY MEMORY
  943.                                    RETURN
  944.                                    * EOF: SUB.PRG
  945.  
  946.  OUTPUT:
  947.  Before call to SUB:
  948.  -------------------
  949.  AREA        priv  N           0  (         0.00000000)
  950.  HEIGHT      priv  N         304  (       304.00000000)
  951.      2 variables defined,       18 bytes used
  952.    254 variables available,   5982 bytes available
  953.  
  954.  Inside SUB:
  955.  -----------
  956.  AREA        priv  N        6000  (      6000.00000000)
  957.  HEIGHT      priv  (hidden)  N         304  (       304.00000000)
  958.  HEIGHT      priv  N          30  (        30.00000000)
  959.      3 variables defined,       27 bytes used
  960.    253 variables available,   5973 bytes available
  961.  
  962.  After call to SUB:
  963.  ------------------
  964.  AREA        priv  N        6000  (      6000.00000000)
  965.  HEIGHT      priv  N         304  (       304.00000000)
  966.      2 variables defined,       18 bytes used
  967.    254 variables available,   5982 bytes available
  968.  
  969.  When DISPLAY MEMORY is entered from the dot prompt the following
  970. two lines will display:
  971.  
  972.     0 variables defined,        0 bytes used
  973.   256 variables available,   6000 bytes available
  974.  
  975.  
  976. title:  PARAMETERS, PASSING FIELDS
  977. version:  10 11 DR
  978. date:  10 Mar 1986
  979. text: 
  980. In the documentation concerning PARAMETERS when used in
  981. conjunction with the DO <filename> [WITH <parameter list>]
  982. command, page 4-76 of the version 1.0 manual states, "A passed
  983. parameter may be any legitimate expression."  Also, in the
  984. Glossary (page 7-3) the definition for Expression is, "Expression
  985. may consist of a field, a memory variable, a function, a
  986. constant, or any combination thereof."  However, when a DO is
  987. invoked with a field in the parameter list, dBASE III will give
  988. the message, "Variable not found."
  989.  In order to use a field name in the parameter list, you must use
  990. the Alias -> Fieldname form.  For example:
  991.  
  992.      USE Filea
  993.      DO <Filename> WITH Filea -> Field1
  994.  
  995.  will work, but the following will not.
  996.  
  997.      USE Filea
  998.      DO <Filename> WITH Field1
  999.  
  1000.  
  1001. title:  NUMERIC INPUT OF LARGE NUMBERS
  1002. version:  10 11
  1003. date:  10 Mar 1986
  1004. text: 
  1005. If a variable is initialized to zero, dBASE III does not allow
  1006. input larger than 10 digits when using the @...GET command, even
  1007. if the PICTURE clause is used.  For example:
  1008.  
  1009.     x = 0
  1010.     @ 5,5 SAY "Enter digits" GET x PICTURE "99999999999"
  1011.     *      (There are eleven 9's) ----------
  1012.     READ
  1013.  
  1014.     The display is:
  1015.  
  1016.             Enter digits           0
  1017.  
  1018.     If an eleven digit value is entered, the display is:
  1019.  
  1020.             Enter digits  **********  (10 asterisks)
  1021.  
  1022.  This can be avoided by initializing 'x' to a value greater than
  1023. ten digits (such as, 1000000000).  This problem does not occur if
  1024. a field is used rather than a memory variable.
  1025.  
  1026.  
  1027. title:  NUMERIC FIELDS WITH DECIMAL PLACES
  1028. version:  10 11 DR
  1029. date:  10 Mar 1986
  1030. text: 
  1031. Although not documented, dBASE III expects the user to allow for
  1032. a leading digit and a decimal point on numeric fields containing
  1033. decimal places.  For example, a numeric field of two decimal
  1034. places should not be defined any smaller than four digits in
  1035. length--one position for the leading digit, one position for the
  1036. decimal point, and two positions for the two decimal places.
  1037.  If the structure for a numeric field does not allow for a leading
  1038. digit (such as, a width of three and two decimal places), numeric
  1039. input to the numeric field will always be stored as zero.  Also,
  1040. if other numeric fields follow this field, they might
  1041. automatically be zeroed out when numeric data is entered to the
  1042. first field.
  1043.  
  1044.  
  1045. title:  LOCATE AND CONTINUE
  1046. version:  10 11
  1047. date:  10 Mar 1986
  1048. text: 
  1049. The LOCATE and CONTINUE commands cannot be used between two or more work areas
  1050. at the same time.  If a LOCATE is issued in one work area, then issued again
  1051. in another work area, a CONTINUE in the original work area will result in a
  1052. SKIP to the next record, not a CONTINUE.  The following program segment
  1053. illustrates how to LOCATE and CONTINUE between two data files.
  1054.  
  1055.      SELECT 2
  1056.      USE Test
  1057.      SELECT 1
  1058.      USE Test1
  1059.      LOCATE FOR One > 1
  1060.      DO WHILE .NOT. EOF()
  1061.         ? "FIELD Test1->One: " , One
  1062.         SELECT 2
  1063.         LOCATE FOR one > 1
  1064.         DO WHILE .NOT. EOF()
  1065.            ? "FIELD Test->One: ", One
  1066.            SKIP
  1067.            LOCATE NEXT 1000 FOR One > 1
  1068.         ENDDO            -------------- should be larger
  1069.         SELECT 1                         than last record
  1070.         SKIP                             number in file.
  1071.         LOCATE NEXT 1000 FOR One > 1
  1072.      ENDDO
  1073.  
  1074.  The dBASE III Reference Manual entry for MODIFY LABEL, states
  1075. that "when you place several field names on one line of the LABEL
  1076. contents screen, dBASE III eliminates the extra blank spaces and
  1077. prints the label with only one space between fields."  This
  1078. should read, "when you place several field names, separated by
  1079. commas, on one line, etc."  Concatenations of fields appear as
  1080. they always do.
  1081.  
  1082.  
  1083. title:  LABEL FORM COMMAND
  1084. version:  10 11
  1085. date:  10 Mar 1986
  1086. text: 
  1087. If TRIM() functions are the only expressions on a line in a LABEL FORM, dBASE
  1088. III will return "*** Execution error on SUBSTR(): start point out of range"
  1089. when the LABEL FORM encounters a record in which all TRIMmed fields are blank.
  1090.  
  1091.  
  1092. title:  MODIFY STRUCTURE
  1093. version:  10 11 DR
  1094. date:  10 Mar 1986
  1095. text: 
  1096. The "Warning" in the documentation on page 4-73 of dBASE III
  1097. version 1.00 and WARNING of page 4-80 of dBASE III version 1.10
  1098. should read as follows:
  1099.  
  1100.      WARNING: Although you may change field names and field
  1101.      lengths, if you change both at once, the data of the
  1102.      fields that have been modified will not be appended
  1103.      into the new structure.
  1104.  
  1105.  Note that in the ASSIST mode, the following screen message is not
  1106. entirely true, "Information in the database file is preserved
  1107. where field names remain the same."  As noted above, if only
  1108. field names are changed or only the length, the data is appended
  1109. into the new structure.  The correct procedure when both field
  1110. name(s) and field length(s) need to be changed, is to modify the
  1111. field name(s) first, and then re-enter MODIFY STRUCTURE and
  1112. modify the field length(s).
  1113.  Also, note that deleting a field (with Ctrl-U) has the same
  1114. effect as modifying the field length.  Therefore, make deletions
  1115. at the same time you make field length changes.
  1116.  
  1117.  
  1118. title:  MODIFY STRUCTURE
  1119. version:  10 11 DR
  1120. date:  10 Mar 1986
  1121. text: 
  1122. In MODIFY STRUCTURE, Ctrl-Home will bring up a menu on line 0 with
  1123. the four choices listed below.
  1124.  
  1125.      Bottom        Top       Field #     Menu
  1126.  
  1127.  They are selected with cursor control keys and <RETURN>.
  1128. Bottom moves the cursor to the last field, Top to the first.
  1129. Field # allows selection of a field number, then moves the
  1130. cursor to it.  Menu toggles the cursor control menu off and
  1131. on.  This feature is not documented under MODIFY STRUCTURE.
  1132.  
  1133.  
  1134. title:  MEMO FIELDS
  1135. version:  10 11
  1136. date:  10 Mar 1986
  1137. text: 
  1138. (1) MEMO fields are used to contain up to 5,000 characters of
  1139. text information that is to be associated with a database record.
  1140. Information may be read into a MEMO field using Ctrl-K-R and
  1141. written to text files using Ctrl-K-W. Information from MEMO
  1142. fields can be displayed or printed by using LIST, DISPLAY, ?.
  1143. The field must be specified  with these commands.  However, these
  1144. commands cause the MEMO field to wrap at 50 columns.  The REPORT
  1145. FORM may be used to output MEMO fields with line widths of more
  1146. or less than 50 characters.
  1147. (2) PACKing a database file with memo fields will not decrease
  1148. the amount of disk space used by the .DBT file.  The command file
  1149. below demonstrates how to remove the deleted records and free the
  1150. unused disk space.
  1151.  
  1152.      SET DELETED ON
  1153.      USE Filea
  1154.      COPY TO Temp
  1155.      CLOSE DATABASE
  1156.      ERASE Filea.dbf
  1157.      ERASE Filea.dbt
  1158.      RENAME Temp.dbf TO Filea.dbf
  1159.      RENAME Temp.dbt TO Filea.dbt
  1160.      SET DELETED OFF
  1161.  
  1162. (3) When APPENDing FROM a database file with a memo field, the
  1163. target .DBT file will be at least as large as the source .DBT
  1164. regardless of how many records are APPENDed.  This is because
  1165. the target .DBT file contains all the information that was
  1166. contained in the source .DBT file.  Be sure to note this any
  1167. time you are moving records from one database file that
  1168. contains memo fields to another.  There is a danger of
  1169. unexpectedly filling a disk when doing this operation.
  1170.  
  1171.  
  1172. title:  MACRO (&) SUBSTITUTION IN A FORMAT (.FMT) FILE
  1173. version:  10 11 DR
  1174. date:  10 Mar 1986
  1175. text: 
  1176. Macro (&) substitution will not work in a format (.FMT) file.
  1177. For example:
  1178.      Structure for database: Macro.DBF
  1179.      Number of records:
  1180.      Date of last update:  5/01/85
  1181.      Field     Field name     Type          Width     Dec
  1182.          1     FLD01          Character        10
  1183.          2     FLD02          Character        10
  1184.          3     FLD03          Character        10
  1185.      ** Total **                               30
  1186.  
  1187.      * Program..: Macro.PRG
  1188.      * Note.....: This program will not display any field from
  1189.      *            the database file.
  1190.      CLEAR
  1191.      PUBLIC month
  1192.      month = "  "
  1193.      USE Macro
  1194.      ACCEPT "Enter two digits 01, 02, or 03: " TO month
  1195.      SET FORMAT TO Macro
  1196.      READ
  1197.      CLOSE FORMAT
  1198.      CLEAR
  1199.      RETURN
  1200.  
  1201.      Macro.FMT contains one line:
  1202.      @ 05,30 SAY Fld&month
  1203.  
  1204. If the SET FORMAT TO Macro, READ, and CLOSE FORMAT command lines
  1205. are removed and DO Macro.FMT is inserted in their place, the
  1206. program will execute as expected and the field will be displayed.
  1207.  
  1208.  
  1209. title:  INPUT AND NEW MEMVARS
  1210. version:  10
  1211. date:  10 Mar 1986
  1212. text: 
  1213. The INPUT command does not initialize a memory variable of any
  1214. type if <RETURN> is pressed at its prompt.  The dBASE III manual
  1215. says this will produce a syntax error (page 4-58).  What really
  1216. happens is that a syntax error will result if the non-existent
  1217. memvar is later referenced.
  1218.  
  1219.  
  1220. title:  CTOD() FUNCTION
  1221. version:  10 11 DR
  1222. date:  10 Mar 1986
  1223. text: 
  1224. The dBASE III Reference Manual does not clearly state that the CTOD() function
  1225. will convert invalid dates to valid dates.  The day is adjusted first.
  1226.  
  1227.      ? CTOD("02/29/85")
  1228.      03/01/85  <------------ Extra day is added to month.
  1229.      ? CTOD("02/29/84")
  1230.      02/29/84  <------------ Leap years are correct.
  1231.  
  1232.  If the month is invalid, it is divided by twelve and the year is adjusted.
  1233. For example:
  1234.  
  1235.      ? CTOD("13/01/84")
  1236.      01/01/85  <------------ Extra month is added to year.
  1237.      ? CTOD("12/32/84")
  1238.      01/01/85  <------------ Extra day is added to month,
  1239.                              extra month is added to year.
  1240.      ? CTOD("99/99/62")
  1241.      06/23/70
  1242.  
  1243. title:  FILE() FUNCTION
  1244. version:  10 11
  1245. date:  10 Mar 1986
  1246. text: 
  1247. The FILE() function only searches the current directory.  SET
  1248. PATH TO does not affect this function.  If other directories are
  1249. to be searched, they must be supplied to the function.  For
  1250. example,
  1251.  
  1252.      * ---This will not find Data.dbf, if Data.dbf is in the
  1253.      * ---subdirectory ACCTS.
  1254.      SET QH TO            DBASE                                              
  1255. ACCTS
  1256.      IF FILE( "DATA.DBF" )
  1257.         DO Process
  1258.      ENDIF
  1259.  
  1260.  Workaround:
  1261.  
  1262.      * ---This method will work.
  1263.      mpath = "             DBASE                                              
  1264. ACCTS "
  1265.      SET PATH TO &mpath
  1266.      IF FILE( mpath + "DATA.DBF" )
  1267.         DO Process
  1268.      ENDIF
  1269.  
  1270.  
  1271. title:  DUPLICATE KEYWORDS IN CONFIG.DB
  1272. version:  10 11 DR
  1273. date:  10 Mar 1986
  1274. text: 
  1275. If two or more COMMAND = <value> lines are contained in the
  1276. Config.DB file, only the last COMMAND will execute.  This is true
  1277. of any duplicate <keyword> = <value> entry in the Config.DB file,
  1278. with the exception of DELIMITERS, which can legitimately have two
  1279. entries.
  1280.  
  1281.  
  1282. title:  DISPLAY AND LIST
  1283. version:  10
  1284. date:  10 Mar 1986
  1285. text: 
  1286. The DISPLAY and LIST commands are documented in the manual as not
  1287. having a FIELDS clause as part of the syntax, while the ASSIST
  1288. and HELP menu options assume the FIELDS clause is required.
  1289. dBASE III will accept either syntax for these two commands.
  1290.  
  1291.  
  1292. title:  DEBUGGING TIP
  1293. version:  10 11
  1294. date:  10 Mar 1986
  1295. text: 
  1296. The RETURN and CANCEL commands will release all PRIVATE memory variables
  1297. when returning to the dot prompt.  This can make debugging difficult
  1298. with versions 1.0 and 1.1 as you may want to check the status of
  1299. variables used by the program.  The following debugging utility can be
  1300. set up as a command file.  This utility, called Dot.PRG, will allow
  1301. you to interactively enter commands, such as LIST MEMORY and LIST
  1302. STATUS.
  1303.  You can insert the command "DO Dot" at various problem points in your
  1304. program.  When this command is encountered, you will be able to enter
  1305. interactive commands without destroying the current environment of the
  1306. program at runtime.  Once the program is fully debugged, you can
  1307. remove the "DO Dot" command lines.
  1308.  
  1309.      * Dot.PRG
  1310.      DO WHILE .T.
  1311.         ACCEPT 'DOT  ' TO command
  1312.         IF LEN( TRIM(command) ) = 0
  1313.            EXIT
  1314.         ENDIF
  1315.         &command
  1316.      ENDDO
  1317.      RETURN
  1318.  
  1319.  
  1320. title:  DATES THAT ARE BLANK
  1321. version:  10 11 DR
  1322. date:  10 Mar 1986
  1323. text: 
  1324. CTOD() and DTOC() are intended to be inverse functions.  That is,
  1325. if DTOC(date) = char, then CTOD(char) = date.  This is true in
  1326. all circumstances except when the date is blank and the character
  1327. string is " / / ".  To detect a blank date, you must use the
  1328. DTOC() function rather than CTOD().  For example:
  1329.  
  1330.      reg_date = CTOD("11/09/84")
  1331.      ? reg_date = CTOD("11/09/84")
  1332.      .T.
  1333.      ? DTOC(reg_date) = "11/09/84"
  1334.      .T.
  1335.      * ---With a blank date the following occurs:
  1336.      blank_date = CTOD("  /  /  ")
  1337.      ? blank_date = CTOD("  /  /  ")
  1338.      .F.
  1339.      ? DTOC(blank_date) = "  /  /  "
  1340.      .T.
  1341.  
  1342.  As is evident from the example, the blank date is handled
  1343. differently than the non-blank date.
  1344.  
  1345.  
  1346. title:  DATE CONVERSION FROM DBASE II
  1347. version:  10 11 DR
  1348. date:  10 Mar 1986
  1349. text: 
  1350. The dBASE BRIDGE manual (pages 23-24) lays out an elaborate
  1351. scheme for converting dBASE II "dates" to dBASE III date fields.
  1352. A much easier way is to simply convert the dBASE II database file
  1353. to a dBASE III file and modify the structure from character to
  1354. date field.  All dates stored in a dBASE II character field as
  1355. "MM/DD/YY" will directly convert to a dBASE III date field.
  1356.  
  1357.  
  1358. title:  CREATE/MODIFY REPORT
  1359. version:  10 11 DR
  1360. date:  10 Mar 1986
  1361. text: 
  1362. When you get the error message "Internal error - bucket overfilled"
  1363. while in CREATE REPORT or MODIFY REPORT, you have too many characters
  1364. in the report.  The maximum number of characters, or bucket size, is
  1365. 1,440 bytes.  This includes the number of characters in the following
  1366. list:
  1367.  
  1368.      Report heading          - plus one byte for each line
  1369.      Subtotal heading(s)     - plus one byte for each line
  1370.      Subtotal expression(s)  - plus one byte for each expression
  1371.      Field heading(s)        - plus one byte for each line
  1372.      Field expression(s)     - plus one byte for each expression
  1373.  
  1374.  The extra byte is a null terminator for each expression and heading.
  1375. When there are multiple lines in a heading, dBASE III separates them
  1376. with a semicolon in the .FRM file.
  1377.  
  1378.  
  1379. title:  COPY STRUCTURE EXTENDED / CREATE FROM
  1380. version:  10
  1381. date:  10 Mar 1986
  1382. text: 
  1383. COPY STRUCTURE EXTENDED and CREATE FROM are fully implemented in
  1384. dBASE III although not documented.  A brief description is given
  1385. below.
  1386.  
  1387.   1) COPY STRUCTURE EXTENDED creates a file in which the field
  1388.      names become the contents of one record.  The syntax for
  1389.      this COPY option is:
  1390.  
  1391.           COPY STRUCTURE EXTENDED TO <new file>
  1392.  
  1393.   2) CREATE FROM forms a new database (.DBF) file in which the
  1394.      structure is determined by the contents of a file created
  1395.      with COPY STRUCTURE EXTENDED.  The syntax is:
  1396.  
  1397.           CREATE <new file> FROM <structure extended file>
  1398.  
  1399. title:  COPY FILE <SOURCE FILENAME> TO <TARGET FILENAME>
  1400. version:  10 11 DR
  1401. date:  10 Mar 1986
  1402. text: 
  1403. The COPY FILE command copies files in 512 byte blocks; whereas,
  1404. the COPY TO command will copy a .DBF file until the end-of-file.
  1405. Therefore, the COPY FILE command will usually create a slightly
  1406. larger file than the COPY TO command.  However, the COPY FILE is
  1407. faster.
  1408.  
  1409.  
  1410. title:  COPY TO <FILENAME> [SDF/DELIMITED [WITH <DELIMITER>]]
  1411. version:  10 11 DR
  1412. date:  10 Mar 1986
  1413. text: 
  1414. (1) COPY TO <filename> DELIMITED does not enclose logical fields
  1415. with the specified delimiters.   Numeric and date fields are also
  1416. treated this way.  Date fields go out in the format YYYYMMDD.
  1417.  
  1418. (2) COPY TO <filename> DELIMITED WITH , encloses the character
  1419. fields in commas and separates the fields with another comma.
  1420. This command behaves differently from dBASE II as shown below:
  1421.  
  1422.  In dBASE II:
  1423.   . USE file1
  1424.   . COPY TO file2 DELIMITED WITH ,
  1425.  
  1426.  will result in:
  1427.   SANTA,CLAUS,NORTH POLE,ALASKA
  1428.  
  1429.  In dBASE III:
  1430.   . USE file1
  1431.   . COPY TO file2 DELIMITED WITH ,
  1432.  
  1433.  will result in:
  1434.   ,SANTA,,,CLAUS,,,NORTH POLE,,,ALASKA,
  1435.  
  1436.  
  1437. title:  CLOSING DATABASE FILES
  1438. version:  10 11 DR
  1439. date:  10 Mar 1986
  1440. text: 
  1441. Do not swap data disks without first closing all the open files on the
  1442. original disk.  Not doing so will cause the loss of data in buffers,
  1443. and will also write a new entry in the directory of the new disk.  USE
  1444. will close the currently SELECTed database file and CLOSE DATABASES
  1445. will close all database files in all work areas.  CLEAR ALL also
  1446. closes all open database files and will also release all memory
  1447. variables.  QUIT closes all files, releases all variables, and exits
  1448. dBASE III.  Choose one of these commands to close your files before
  1449. swapping data disks.
  1450.  
  1451.  
  1452. title:  APPEND FROM <FILENAME> [SDF/DELIMITED [WITH <DELIMITER>]]
  1453. version:  10
  1454. date:  10 Mar 1986
  1455. text: 
  1456. The DELIMITED form of the APPEND FROM command should be
  1457. documented as having a WITH clause.  WITH is not mentioned
  1458. in the reference section.  Below are a few examples:
  1459.  
  1460.  Example 1. To read a comma delimited file in which the
  1461.             character strings are enclosed in double quotes:
  1462.  
  1463.             APPEND FROM <filename> DELIMITED
  1464.          or
  1465.             APPEND FROM <filename> DELIMITED WITH "
  1466.  
  1467.  Example 2. To read a comma delimited file in which the
  1468.             character strings are enclosed in single quotes:
  1469.  
  1470.             APPEND FROM <filename> DELIMITED WITH '
  1471.  
  1472.  Example 3. To read a comma delimited file in which the
  1473.             character strings are not enclosed at all:
  1474.  
  1475.             dBASE III CANNOT READ A FILE OF THIS FORMAT!
  1476.  
  1477.  Also, the syntax of the APPEND command does not include a WHILE
  1478. option as the manual indicates.  The correct syntax is
  1479.  
  1480.      APPEND FROM <file name> [FOR <condition>]
  1481.             [SDF/DELIMITED [WITH <delimiter>]]
  1482.  
  1483.  APPEND FROM <textfile> SDF expects records in the text file to be
  1484. terminated with a carriage return/line feed (0DH 0AH) pair, in this
  1485. order.  If the order is reversed (0AH 0DH), dBASE III ignores the
  1486. character following the carriage return.  This causes the first
  1487. character of every record (after the first record) to be missed in the
  1488. resultant database file.
  1489.  
  1490.  
  1491. title:  @ SAY PICTURE
  1492. version:  10 11 DR
  1493. date:  10 Mar 1986
  1494. text: 
  1495. To display a dollar-sign character ("$") in front of a numeric
  1496. value and not have the possibility of a lot of "$"s filling the
  1497. blank areas, do the following:
  1498.  
  1499.      * ---To display a single "$".
  1500.      STORE 123.56 TO num
  1501.      @ 10,10 SAY "$"
  1502.      @ 10,11 SAY num PICTURE "99,999.99"
  1503.  
  1504.      This will generate:
  1505.  
  1506.                $  123.56
  1507.  
  1508.      * ---The other option available is:
  1509.      STORE 123.56 TO num
  1510.      @ 10,10 SAY num PICTURE "$$,$$$.$$"
  1511.  
  1512.      This will generate:
  1513.  
  1514.                $$$123.56
  1515.  
  1516.  
  1517. title:  @ GET AND READ
  1518. version:  10 11
  1519. date:  10 Mar 1986
  1520. text: 
  1521. (1) If an attempt is made to @...GET memvar PICTURE "999.99" and
  1522. the memory variable is not initialized with the number of decimal
  1523. places specified in the PICTURE clause, the GET display will not
  1524. show the decimal digits for input.  Entering a decimal point will
  1525. exit the GET.  For example:
  1526.  
  1527.     * ---Set up numeric input.
  1528.     num = 0
  1529.     @ 10,10 SAY "Enter number " GET num PICTURE "999.99"
  1530.     READ
  1531.     *
  1532.     * ---After entering a decimal point during the READ,
  1533.     * ---the GET will display the following:
  1534.  
  1535.         Enter number :  0.  :
  1536.  
  1537.  To properly input numeric memory variables with decimal digits
  1538. using @...GET...PICTURE, initialize the memory variable with the
  1539. number of decimal digits used in the PICTURE clause.  For
  1540. example:
  1541.  
  1542.     * ---The following command line assigns num with
  1543.     * ---the same number of decimal digits as found
  1544.     * ---in the PICTURE clause.
  1545.     num = 0.00
  1546.     @ 10,10 SAY "Enter number " GET num PICTURE "999.99"
  1547.     READ
  1548.  
  1549.  (2) When using @...GET and READ certain keys will terminate the
  1550. READ. The following table shows which keys do so and where in the
  1551. pending GETs the key will terminate the READ.
  1552.  
  1553.     Key:        The READ will terminate at:
  1554.     ----------- ---------------------------
  1555.     Backspace    First character of first GET
  1556.     Left arrow   First character of first GET
  1557.     Right arrow  Last character of last GET
  1558.     Up arrow     First GET
  1559.     Down arrow   Last GET
  1560.     Esc          Anywhere
  1561.     F1           Anywhere
  1562.     Ctrl-[       Anywhere
  1563.     Ctrl-Q       Anywhere
  1564.     Ctrl-W       Anywhere
  1565.     Ctrl-Home    Anywhere
  1566.     Ctrl-End     Anywhere
  1567.     PgUp         Anywhere
  1568.     PgDn         Anywhere
  1569.     Ctrl-PgUp    Anywhere
  1570.     Ctrl-PgDn    Anywhere
  1571.     Alt 0-9      Anywhere
  1572.  
  1573.  
  1574.  
  1575. RETURN to continue or <H>elp: 
  1576.  
  1577. 63 item(s) found 
  1578.