home *** CD-ROM | disk | FTP | other *** search
/ Black Box 4 / BlackBox.cdr / dbase / tn9101.arj / MNULOVWT.TXT < prev    next >
Encoding:
Text File  |  1991-03-05  |  8.2 KB  |  225 lines
  1.  
  2. This article is reprinted from the January 1991 edition of
  3. TechNotes/dBASE IV.  Due to the limitations of this media, certain
  4. graphic elements such as screen shots, illustrations and some tables
  5. have been omitted.  Where possible, reference to such items has been
  6. deleted.  As a result, continuity may be compromised.  
  7.  
  8. TechNotes is a monthly publication from the Ashton-Tate Software
  9. Support Center.  For subscription information, call 800-545-9364.
  10.  
  11. Understanding SCAN,
  12. SET options, Using Aliases
  13.  
  14. Nesting SCANs
  15.  
  16. To help reduce the amount of dBASE code necessary to produce a
  17. program, the designers of the dBASE language have introduced the
  18. SCAN.ENDSCAN command structure.  This construct is designed to take
  19. the place of the LOCATE, DO WHILE, SKIP/CONTINUE, ENDDO sequence of
  20. commands.  Traditionally,  looping structures prior to dBASE IV would
  21. look like this. 
  22.  
  23. GO TOP
  24. DO WHILE .NOT. EOF()
  25.                 .
  26.                 * Process this record
  27.                 .
  28.                 SKIP
  29. ENDDO
  30.  
  31. OR
  32.  
  33. LOCATE FOR <cond>
  34. DO WHILE <cond> .AND. .NOT. EOF()
  35.                 .
  36.                 * Process this record
  37.                 .
  38.                 CONTINUE
  39. ENDDO
  40.  
  41. SCAN.ENDSCAN can make this a little smaller by coding it like this:
  42.  
  43. SCAN
  44.                 .
  45.                 * Process this record
  46.                 .
  47. ENDSCAN
  48.  
  49. or
  50.  
  51. SCAN FOR <cond>
  52.                 .
  53.                 * Process this record
  54.                 .
  55. ENDSCAN
  56.  
  57. However, do not assume that SCAN will apparently work in the exact
  58. same way the common DO WHILE loop does.  Particularly, nesting
  59. SCAN.ENDSCAN loops may lead to some unexpected results.  To
  60. illustrate, let's examine a SCAN loop more closely.  
  61.  
  62. The SCAN command itself behaves like a GO TOP followed immediately by
  63. a DO WHILE .NOT. EOF().  SCAN with a scope, FOR clause, and/or a WHERE
  64. clause behaves exactly like a LOCATE with the same clause(s)
  65. immediately followed by a DO WHILE FOUND() command.  Then comes the
  66. body of the loop.  Lastly, the ENDSCAN command behaves like SKIP
  67. followed by ENDDO if the SCAN had no FOR clauses following it. 
  68. Otherwise, ENDSCAN behaves like CONTINUE followed by ENDDO.  Still,
  69. nothing is apparently amiss here.that is, until SCANs are nested.  An
  70. almost invisible phenomenon occurs.  As the following listing
  71. illustrates, two SCANs means two ENDSCANs, therefore the record
  72. pointer is moved twice between groups of data.  Put plainly, you're
  73. skipping once more than is obvious, and thereby missing a record of
  74. possibly needed information.  What's more, if the end-of-file is
  75. reached within the inner SCAN loop, an "End of file encountered" error
  76. message is produced upon encountering the ENDSCAN command of the outer
  77. SCAN loop.  Use SCAN.ENDSCAN thoughtfully! 
  78.  
  79. SCAN
  80.                 SCAN FOR <cond>
  81.                 .
  82.                 * Process this record
  83.                 .
  84.                 ENDSCAN                 && A SKIP or CONTINUE is executed
  85. here...
  86.                 .
  87. ENDSCAN                                 && And here as well!
  88.  
  89. SET DIRECTORY, SET DEFAULT and RUN CD
  90.  
  91. The SET DIRECTORY command has made its appearance in dBASE IV version
  92. 1.1.  This new command extends the SET DEFAULT functionality by
  93. allowing a drive and a directory to be specified.  This capability was
  94. available in version 1.0, but only through the DOS Utilities section
  95. of the Control Center.  When a SET DIRECTORY command is issued, the
  96. current DEFAULT drive is also changed to reflect the same drive, but
  97. issuing a SET DEFAULT TO <drive:> command does not have the reverse
  98. effect.  SETting DEFAULT never has an effect on the current DOS drive,
  99. so disagreement between DOS and dBASE IV could occur.  SETting
  100. DIRECTORY does affect the current DOS drive and directory, however. 
  101. Another, less obvious, difference between the SET DIRECTORY and SET
  102. DEFAULT commands is that SET DEFAULT does not "talk".  That is, if
  103. TALK is ON, a SET DIRECTORY command will display the current drive and
  104. directory on the screen; SET DEFAULT will display nothing.  Lastly,
  105. determining the current SET DIRECTORY and SET DEFAULT settings is also
  106. available now using the SET() function in this way:
  107.  
  108. homedir         = SET("DIRECTORY")
  109. defadrive               = SET("DEFAULT")
  110.  
  111. Even though this feature affords the dBASE IV programmer greater
  112. flexibility and control, a word of caution to veteran programmers may
  113. be in order.  Once the current drive and/or directory is changed with
  114. the SET DIRECTORY command, that new path is saved in dBASE memory. 
  115. Changing the current DOS directory through the use of the RUN/!
  116. command, a TSR, or a .BIN file, therefore, may not necessarily reflect
  117. the dBASE SET DIRECTORY setting.  The following code sample
  118. illustrates this. 
  119.  
  120. . ? SET("DIRECTORY")
  121. C:\DBASE
  122. . ! CD
  123. C:\DBASE                                && dBase and DOS agree here...
  124.  
  125. . ! CD SAMPLES
  126.  
  127. . ! CD
  128. C:\DBASE\SAMPLES
  129.  
  130. . ? SET("DIRECTORY")
  131. C:\DBASE                                && But not here!
  132.  
  133. So, depending on the order of their issuance, SET("DEFAULT"),
  134. SET("DIRECTORY") and ! CD may point to completely disparate entities. 
  135. To complicate matters, when accessing dBASE IV related files
  136. (programs, data files, labels, and so on) the dBASE IV DEFAULT setting
  137. will be respected implicitly, regardless of the SET DIRECTORY status
  138. or the current DOS drive. 
  139.  
  140. Getting SET DIRECTORY, SET DEFAULT and DOS to agree may be
  141. accomplished by using special forms of the SET DIRECTORY command.  If
  142. the current drive has not been changed, issuing
  143.  
  144. SET DIRECTORY TO .                              && period character
  145.  
  146. will change the dBASE SET DIRECTORY setting to reflect the DOS current
  147. directory and force SET DEFAULT to reflect the current drive. 
  148. Entering SET DIRECTORY TO by itself with no final parameter will
  149. change back to that directory from which dBASE IV was started.  If the
  150. drive has been changed, however the following sequence of commands may
  151. be employed. 
  152.  
  153. . SET DEFAULT TO
  154. . here = SET("DEFAULT") + "."
  155. . SET DIRECTORY TO &here
  156.  
  157. This command sequence forces dBASE IV to agree with DOS.  One could
  158. say that with added power, comes added responsibility.  
  159.  
  160. Functions and Aliases
  161.  
  162. The following sequence of commands is likely to be familiar to dBASE
  163. programmers.
  164.  
  165. SELECT B
  166. at_end = EOF()
  167. SELECT A
  168. IF at_end
  169. ∙
  170. ∙
  171.  
  172. When you wanted to determine conditions which are data file related,
  173. such as EOF(), RECNO(), or LUPDATE(), it was necessary to change work
  174. areas, invoke the required function and then return to the previous
  175. work area. 
  176.  
  177. With dBASE IV, the previous command sequence can be comfortably
  178. reduced to one or, at most, two lines of program code.  The following
  179. line of code illustrates. 
  180.  
  181. IF EOF("B")
  182.                 .
  183.                 .
  184. ENDIF
  185.  
  186. These functions are not the only extension to dBASE IV that allows a
  187. programmer to specify operational work areas.  GO/GOTO, LIST/DISPLAY
  188. STRUCTURE, RESET, SKIP, UNLOCK and USE now allow the use of an IN
  189. clause.  For example, 
  190.  
  191. GOTO BOTTOM IN B
  192.  
  193. would instruct dBASE IV to position the record pointer in work area B
  194. to the last logical record and no need to change work areas is
  195. required.  
  196.  
  197. Despite the obvious ease and power that you gain through the use of
  198. this method of alias referencing, there's a bit of confusion over how
  199. to properly specify an alias, syntactically speaking.  The rules are
  200. simple.  If you are using a command, just about anything goes. 
  201. Assuming that Customer.DBF is USEd in work area 3, any of the
  202. following examples is valid: 
  203.  
  204.  
  205. GOTO TOP IN 3                   && numeric literal...
  206. GOTO TOP IN (12/4)                      && numeric expression...
  207. GOTO TOP IN C                   && predefined alias specifier
  208. GOTO TOP IN CHR(67)             && character exp./literal
  209. GOTO TOP IN "C"                 &&  indicating a predefined 
  210.                                         && alias specifier
  211. GOTO TOP IN Customer            && An alias name 
  212.                                         && the default in this case
  213. GOTO TOP IN "Customer"          && A character literal
  214.                                         && indicating an alias 
  215.  
  216. For functions, it's a little more restrictive; only character or
  217. numeric values are permissible.  
  218.  
  219. mvar = RECNO(3)
  220. mvar = RECNO(INT(PI()))
  221. mvar = RECNO("C")
  222. mvar = RECNO("Customer")
  223.  
  224.  
  225.