- Locating dBASE III Anomalies and Workarounds -
( from the Source - Ashton Tate SIG - ATSIG )

108 item(s) found for  ALL


title:  USING SUSPEND WITH ON (DEVELOPER'S RELEASE)
version:  DR
date:  10 Mar 1986
text: 
Using the SUSPEND command with the ON command in a program may
cause some unexpected results.  The command:

ON KEY SUSPEND

in a program will return the error message, "Valid only in
programs" when a key is pressed.  The program, however, will be
SUSPENDed.

The command:

ON ERROR SUSPEND

behaves erratically.  It will SUSPEND the program, although
RESUME may have to be entered twice before the program actually
resumes execution.



title: SET FILTER TO EXPRESSION IN PARENTHESIS 
       (DEVELOPER'S RELEASE AND RUNTIME+)
version:  DR
date:  10 Mar 1986
text: 

If a SET FILTER TO command has a parenthesis following the TO
and is encrypted using DBC.COM, that command line will produce
the error message "Invalid function name" when it is run from
dBRUN or dBASE III Developer's Release.  The command:

SET FILTER TO (F1 = 2 .OR. F2 = 2) .AND. F3 > 1

will produce this error when encrypted and run.  To work
around, build the FILTER expression by placing the simplest
non-grouped subexpression first and then begin the grouped
subexpressions.  For example:

SET FILTER TO F3 > 1 .AND. (F1 = 2 .OR. F2 = 2)


title:  IIF() NESTTING LIMITATION (DEVELOPERS'S RELEASE)
version:  DR
date:  10 Mar 1986
text: 
There is a limit to the number of times IIF() may be nested.
Nesting this function eight or more deep will return a zero
instead of the designated value.


title:  SORT IGNORES EXTENSION OF RESULTANT DATABASE
version:  10 11 DR
date:  10 Mar 1986
text: 
SORTing to a file with an extension other than .DBF will result
in the extension being ignored and a .DBF extension given to
the new file.  For example:

SORT ON Field1 TO Newfile.NEW

will create Newfile.DBF.


title:  SET TALK ON HAS PRECEDENCE OVER SET CONSOLE OFF
version:  10 11 DR
date:  10 Mar 1986
text: 
For commands that produce a running total or a final result,
such as INDEX or COUNT, the SET TALK ON command takes
precedence over the SET CONSOLE OFF command so that the results
of TALK will be displayed when SET CONSOLE is OFF.  The
following routine demonstrates this.

SET TALK ON
SET CONSOLE OFF
USE Test
COUNT TO memvar <--- The results of COUNT display.
? memvar        <--- This is suppressed by SET TALK OFF.



The SET CONSOLE OFF command in the Developer's Release of dBASE
III does suppress the results of SET TALK ON in all cases.


title:  @ <ROW>, <COL> WITH NO ARGUMENTS
version:  10 11 DR
date:  10 Mar 1986
text: 
An @...SAY statement sent to the printer with no argument and a
row coordinate greater than 24 will return the error message
"SAY/GET position is off the screen."  For example,

SET DEVICE TO PRINT
@ 25,0

The @ <row>, <col> command with no argument clears that row on
the screen beginning at the column position, regardless of the
status of SET DEVICE TO.  Be sure that any @...SAY directed to
the printer has an argument.


title:  CTRL-K-R IN MODIFY COMMAND
version:  10 11
date:  10 Mar 1986
text: 
When using the Ctrl-K-R in the dBASE III word processor, there
is a limit of fifteen characters to the name of the file being
imported.  If the name of the file, including drive designator
and path, is sixteen characters or longer, problems will
occur.  The computer may freeze with the message "File does not
exist (Hit SPACE)" being displayed; or the error message "***
STACK OVERFLOW ***" appears and the user is returned to
PC/MS-DOS.  For example, the filenames:

B:\A\Data10.TXT
B:\Datapath\One

are acceptable, while

B:\A\Data101.TXT <-- "File does not exist (Hit SPACE)"
B:\Datapath\File <-- "*** STACK OVERFLOW ***"

are not.  In the Developer's Release, MODIFY COMMAND will
support filenames including paths exceeding sixteen
characters.


title:  DO PROGRAM CAUSES RETURN POINTERS TO BE LOST
version:  10 11
date:  10 Mar 1986
text: 
Executing a command file with the same name as a procedure in a
procedure file that has been opened and closed causes return
pointers to be lost.  For example, if a file has a nested DO
WHILE, RETURNing from the subprogram will cause the controlling
DO WHILE loop to terminate abnormally.  The program below
demonstrates this problem.

*--- Test.PRG

DO WHILE .T.
  SET PROCEDURE TO Testa
  DO Test1         <-- From Testa.PRG.
  CLOSE PROCEDURE
  DO Test1         <-- Separate command file
ENDDO                 <-- will terminate although no
                      EXIT or RETURN has been executed.

This problem has been corrected in the Developer's Release of
dBASE III.


title:  BROWSE WHEN APPENDING
version:  10 11 DR
date:  10 Mar 1986
text: 
When APPENDing new records with the BROWSE command, dBASE III
will not automatically pan right to allow data entry to fields
that are off the screen.  Instead, the cursor will drop to the
next line and dBASE III will start to enter another record.
Use Ctrl-B and Ctrl-F to pan left or right, respectively, while
APPENDing.


title:  INDEX ON SUBSTR( <FIELD>, N, LEN( <FIELD> )
version:  10 11
date:  10 Mar 1986
text: 
INDEXing a database file with a key expression that includes
the LEN() function as the second argument of the SUBSTR()
function will result in a nonfunctional index file.  For
example:

INDEX ON SUBSTR( <Field>, 1, LEN( <Field> ) ) TO;
Indexfile

will create an index file that appears to be correctly
constructed.  You can FIND or SEEK a record and then EDIT it.
The index file, however is not updated and any attempt to GOTO
a record or BROWSE will return the error message "Record not in
index."

The problem is corrected in the Developer's Release.


title:  DO <PROCEDURE> CANNOT CONTAIN SPECIAL CHARACTERS
version:  10 11 DR
date:  10 Mar 1986
text: 
In dBASE III, PROCEDURE names cannot contain special
characters, although filenames can.  If the name of a PROCEDURE
within a PROCEDURE file contains a special character ($, #, -,
@, etc.), using the DO <procedure> command will return the
error message "Unrecognized phrase/keyword in command."  For
example:

*--- Proc-test.PRG
PROCEDURE Test-it
? 'This is Test-it from Proc-test.PRG'
RETURN
* EOP Proc-test.PRG

*--- Test.PRG
SET PROCEDURE TO Proc-test <--- This works properly.
DO Test-it                 <--- This returns the error
RETURN                          message.
* EOP Test.PRG

Note that this applies only to PROCEDURE names and not to
command files names.  This may be a problem if you have
recently merged command files into a procedure file and your
command filenames contain special characters.


title:  INDEX ON STR()
version:  10 11
date:  10 Mar 1986
text: 
(1) Attempting to INDEX ON the concatenation of many STR() functions
may create an index that is in record number order.  Specifically, if
the length of the key expression is 80 or 90 characters long and
consists solely of a concatenation of STR() functions, the resultant
index file will be in the same order as the database file.  For
example:

    . USE Numfile
    . LIST

    RECORD#    NUM1  NUM2  NUM3  NUM4  NUM5  NUM6  NUM7  NUM8
          1    8     8     8     8     8     8     8     8
          2    7     7     7     7     7     7     7     7
          3    6     6     6     6     6     6     6     6
          4    5     5     5     5     5     5     5     5
          5    4     4     4     4     4     4     4     4
          6    3     3     3     3     3     3     3     3
          7    2     2     2     2     2     2     2     2
          8    1     1     1     1     1     1     1     1

    . INDEX ON STR(Num1,1)+STR(Num2,1)+STR(Num3,1)+STR(Num4,1)
    +STR(Num5,1)+STR(Num6,1)+STR(Num7,1)+STR(Num8,1) TO Numex

    * The key expression in this example is 96 characters long.
    * The expected result is that the records will be in
    * reverse record number order when the index Numex is used.

    . LIST

    RECORD#    NUM1  NUM2  NUM3  NUM4  NUM5  NUM6  NUM7  NUM8
          1    8     8     8     8     8     8     8     8
          2    7     7     7     7     7     7     7     7
          3    6     6     6     6     6     6     6     6
          4    5     5     5     5     5     5     5     5
          5    4     4     4     4     4     4     4     4
          6    3     3     3     3     3     3     3     3
          7    2     2     2     2     2     2     2     2
          8    1     1     1     1     1     1     1     1

    The database file has been indexed in record number order and is
    identical to the unindexed file.

(2) The maximum length of key expression is 100 characters.
In the example above, the key expression is 96 characters long which
is within the limitation.  The maximum length of the key itself is
also 100 characters.  In the example above, the key is 8 characters
long, one character for each field.  If either the key or the key
expression exceeds the 100 character limitation, dBASE III will
normally return the error message "Index is too big (100 char
maximum)".  However, this error is not trapped if the key expression
is formed by the concatenation of STR() functions.  The INDEX command
given in the paragraph above may be lengthened as in the following
example and no error message will result.

    INDEX ON STR(Num1,1)+STR(Num2,1)+STR(Num3,1)+STR(Num4,1)
    +STR(Num5,1)+STR(Num6,1)+STR(Num7,1)+STR(Num8,1)+STR(Num
    1,1) TO Numex

The key expression in this command is 108 characters in length.
No error message is returned when this command is executed, but one of
two errors will occur.  Either the index that is created is still in
record number order as explained in the first paragraph, or dBASE III
will return random error messages as it attempts to create the index.
Because this is not trapped, pay extra attention when you create index
files from a long expression consisting of the concatenation of STR()
functions.


title:  RETURN TO MASTER
version:  10 11
date:  10 Mar 1986
text: 
RETURN TO MASTER will not work properly if it is used in a
PROCEDURE which is called from within a DO WHILE loop with the
MASTER as the calling program.  Specifically, the program will
stop execution upon RETURNing TO the MASTER file.  However,
pressing Esc will allow the user to return to the dBASE III dot
prompt.  For example:

     * Test.PRG
     PUBLIC one
     one = "Y"
     SET PROCEDURE TO Test1
     DO WHILE one = "Y"
        DO Pro_3
        ? "Back IN Test.PRG"
     ENDDO
     CLOSE PROCEDURE
     RETURN

     * Test1.PRG
     PROCEDURE Pro_3
     ? "Now in Pro_3 PROCEDURE in Test1 file"
     RETURN TO MASTER

If RETURN TO MASTER is changed to RETURN, the command file works
properly.  If Test.PRG were to call another file which
then called the procedure file, RETURN TO MASTER will work.


title:  ZAP, PACK, AND INDEX FILES
version:  10 11 DR
date:  10 Mar 1986
text: 
PACKing or ZAPping a database file without its index files in
use, then opening the index files and adding records to the file
will result in multiple record entries in the index files.  For
example, the following command sequence will result in an index
file with two entries for each record in the database file:

     USE File_one INDEX Alpha
     COPY TO New_file
     CLOSE INDEX
     ZAP
     SET INDEX TO Alpha
     APPEND FROM New_file

Ideally, opening the index file after the file has been ZAPped
should be trapped by an error message, such as "End of file
encountered unexpectedly" or "Record out of range".


title:  USE
version:  10 11 DR
date:  10 Mar 1986
text: 
An attempt to use the PC/MS-DOS directory navigation path (..) in
a USE command will give unexpected results.  USEing the database
will make the file active, but there will be no ALIAS.  An
attempt to USE another database file in another SELECT area using
the same technique, will cause the error message "ALIAS name
already in use" to be displayed.

     * ---Open first database file.
     USE ..\nme\Budget
     DISPLAY STATUS

     Currently selected database:
     Select area - 1, Database in use: C:..\nme\Budget.dbf

        Alias -

     * ---Open another database file.
     SELECT 2
     USE ..\nme\Sumfrm
     ALIAS name already in use
                ?
     USE ..\nme\sumfrm

If an ALIAS is assigned in both USE commands, no error results.
If you need to avoid specifying the full path name, use the RUN
command to log the previous directory and then specify the
datafile to USE.  For example,

     RUN CD ..
     USE nme\Budget
     SELECT 2
     USE nme\Sumfrm


title:  TYPE
version:  10 11
date:  10 Mar 1986
text: 
If you attempt to use the following syntax for the TYPE command:

     TYPE <File> TO SCREEN

it will be trapped as an error and give the message, "File does
not exist".  Subsequent attempts to USE or MODIFY the text file
that you wanted to TYPE will return the error message, "File is
already open."  CANCEL or CLEAR ALL will not close the file.
QUITting and re-entering dBASE III is the only option.

The problem is fixed in the Developer's Release.  You will
receive the expected error message, "Syntax error" and the file
being TYPEd will remain properly closed.


title:  TRIM() WITH LIST OR DISPLAY
version:  10 11 DR
date:  10 Mar 1986
text: 
TRIM() will not work with the LIST or DISPLAY commands when the
the function is the last portion of an expression in an
expression list, or the TRIM() is the last portion of an
expression followed by a concatenation of spaces.  For example:

     LIST TRIM(Name), Address
              ^__________________  (note TRIM() is just before
                                    the comma)

     LIST TRIM(Name) + ' ' , Address
                        ^-----------(note TRIM() is followed by a
                                     space then the comma)

TRIM will work, however, when not in the last position of the
expression list.  For example:

     LIST TRIM(Name) + ' ' + Address, City


title:  SUSPEND (DEVELOPER'S RELEASE)
version:  DR
date:  10 Mar 1986
text: 
If you SUSPEND a command file and restart it with DO
<filename> instead of RESUME, dBASE III opens the file
again, without closing the previous session.  The expected error
message "File is currently open" does not appear.  As each file
remains open, this will eventually produce "Too many files are
open."  Issuing the CANCEL command will close every instance of
the open file.

This problem is most likely to occur if you are debugging a
command file and forget that you are still in SUSPEND.  It is
always advisable to RESUME before calling any command file if you
are in the midst of a programming and debugging session.


title:  SUM TO AND PUBLIC MEMORY VARIABLES
version:  10 11
date:  10 Mar 1986
text: 
Attempting to SUM TO memory variables that have been declared as
PUBLIC will usually result in erroneous data.  Initializing the
variables before the SUM command will sometimes, but not always,
correct the error.  In addition to this problem, there is a
practical limit to the number of expressions that may be used in
one SUM command.

In order to use the SUM command reliably, follow these rules.

     1. Do not SUM TO memory variables that are PUBLIC.
        Instead, use PRIVATE variables and STORE the
        results of the SUM to PUBLIC variables.

     2. Limit the number of expressions in the SUM
        command to three or less.


title:  SUM PRODUCES LINEFEEDS
version:  10 11
date:  10 Mar 1986
text: 
The SUM and AVERAGE commands send two linefeeds to both the
screen and printer.  For example, the following command file will
output two extra linefeeds:

     SET TALK OFF
     SET PRINT ON
     ? "Income"
     SUM Income TO inc
     ? inc
     SET PRINT OFF

OUTPUT:

     Income
                    <--+  Two extra linefeeds.
                    <--+
     17384805.00

The only workaround for screen output is to SET CONSOLE OFF when
executing a SUM or an AVERAGE, and SET CONSOLE ON when done.  For
printer output you can use SET PRINT OFF before the command and
SET PRINT ON afterward.


title:  STORE LARGE NUMERIC
version:  10 11
date:  10 Mar 1986
text: 
Attempting to STORE a number with more than 43 digits to a memory
variable will hang the computer and require a warm boot (that is,
Ctrl-Alt-Del). More than 60 digits will require a cold boot (that
is, restarting the system.


title:  STORE
version:  10 11
date:  10 Mar 1986
text: 
STOREing 254 characters to a memory variable will eventually give the "Out of
memory variable memory" error message even though DISPLAY MEMORY shows that
there is memory space available.  With MVARSIZ at the default setting, this
seems to occur after the 23rd attempt to STORE to the memory variable.
Increasing the MVARSIZ will allow more STORE commands, but will eventually
produce this error.  For example, the following set of commands will produce 
the
message after 23 iterations, with MVARSIZ set at the default.

          CLEAR MEMORY
          DO WHILE .T.
             STORE SPACE( 254 ) TO memvar
          ENDDO


title:  SORT WITH 66 RECORDS
version:  10 11
date:  10 Mar 1986
text: 
SORTing a file that has more than 66 records in such
a way that the resulting file has exactly 64 records
will produce a file in which the first record is corrupted.


title:  SORT FOR SUBSTR()
version:  10 11
date:  10 Mar 1986
text: 
Attempting to SORT FOR SUBSTR(fieldname,n,n) = <value> will return
"00% Sorted *** STACK OVERFLOW ***", dropping the user out of dBASE
III to the operating system.


title:  SORT FOR A RANGE OF DATES
version:  10 11
date:  10 Mar 1986
text: 
Attempting to SORT only a subset of a database file based on a
single date or a range of dates may cause a problem if the
following form is used:

     SORT ON <exp> TO <file> FOR DTOC(date)="99/99/99"

where the 9's represent any date.  The error message that will
result is:

     00% Sorted *** STACK OVERFLOW ***

and you will be dropped out of dBASE III to the operating system.
To prevent this problem, use the following form.

     SORT ON <exp> TO <file> FOR date=CTOD("99/99/99")


This work-around will not work for blank dates.  The sort will
appear to execute normally, but no records will be written to the
target file.


title:  SORT
version:  10 11 DR
date:  10 Mar 1986
text: 
(1) Attempting to SORT a file with SET FILTER TO
SUBSTR(fieldname,n,n)  =  <value> will return a "*** STACK
OVERFLOW ***" and  drop you out of dBASE III to the operating
system.
[1.0, 1.1]

(2) SORTing a database file from a command file that is nested 13
levels deep will fail with a system crash.  The SORT command will
return a status message stating that a percentage of the records
in the original file were SORTed, but then the computer will
freeze with no error message or warning.
[1.0, 1.1, D.R.]

(3) Attempting to use the command SORT TO <Filename> ON
<Fieldname> with a RELATION SET produces the error message "***
STACK OVERFLOW ***" and will drop you out of dBASE III to the
operating system prompt.  This will not occur if the RELATION is
SET to RECNO().
[1.0, 1.1]

(4) One cannot SORT to a file in a directory other than the
current one.  An attempt to do this will not produce an error
message and will not create the designated file.  Instead, a file
name W44 will be created in the current directory of the default
drive.
[1.0, 1.1]

(5) The effective limit of SORT is in the 32,000 record range.
SORTing a file with more than 32,000 records will produce the
following error messages:

          nn% Sorted
          Records do not balance...(PROGRAM ERROR)
          100% Sorted

The SORTed file will not contain all the records from the
original.

The workaround for sorting databases in excess of 32,000 records
is to INDEX and then COPY.  The procedure is as follows:

          USE <filename>
          INDEX ON <sort key> to Temp
          COPY TO Sorted
[1.0, 1.1]


title:  SET RELATION TO
version:  10 11
date:  10 Mar 1986
text: 
The command syntax SET RELATION INTO <file> TO <key>  will not
SET the RELATION although no error message is displayed and
DISPLAY STATUS shows the RELATION as SET.

The SET RELATION command is sensitive to the order that the INTO
and the TO clauses are specified.  Apparently, everything after
the INTO clause is ignored.  Be sure to check that you have
specified the TO clause before the INTO clause if your RELATIONs
appear to fail.


title:  SET ORDER TO (DEVELOPER'S RELEASE)
version:  DR
date:  10 Mar 1986
text: 
SET ORDER TO 0 or <space> is intended to cause the database file
to act in physical, unindexed order, while maintaining the
integrity of the open indexes.  However, the indexes are not
updated if the key field is changed.  For example:

   USE <Filename> INDEX <Index1>, <Index2>
   SET ORDER TO
   EDIT         <------ Change key field for Index1.NDX
   SET ORDER TO 1

will produce the error message "Record is not in index."


title:  SET HISTORY TO (DEVELOPER'S RELEASE)
version:  DR
date:  10 Mar 1986
text: 
The SET HISTORY TO command is documented as having a 16,000
command line limit.  However, there are a number of problems that
can occur when a large number is used as its argument.

1. There is no way to escape from a LIST HISTORY.  If you SET
   HISTORY TO a large number, enter a large number of commands,
   and LIST HISTORY, the computer may be tied up for some time as
   the entire contents of HISTORY scroll by.  Pressing Esc will
   not interrupt the LIST.

2. HISTORY appears to use memory without limit. If you SET
   HISTORY TO is a large number, it is possible to use all the
   available memory.  So much memory may be used that it is
   impossible to return to the operating system level.  The error
   message:

          Memory allocation error
           Cannot load COMMAND, system halted

   appears if you attempt to QUIT in such as case.  Setting
   MAXMEM higher than the default will delay, but not prevent the
   problem.

   Furthermore, the dBASE III Reference Manual implies that
                    --------------------------
   HISTORY respects the MAXMEM setting by stating that the RUN
   command may overwrite the HISTORY stack unless MAXMEM is set
   higher than 256K.  However, HISTORY appears to reserve memory
   beyond MAXMEM.  If the number of commands to store in HISTORY
   is SET high and HISTORY contains many entries, attempting the
   RUN command will return the error message, "Insufficient
   memory."

3. There is no error trapping on the upper limit of HISTORY and
   so it is possible to SET it to values higher than 16,000.
   Values less than 1,000,000 appear to work properly, although
   it is not known if more than 16,000 lines of code are stored.

   When the value of HISTORY exceeds 1,000,000, the HISTORY
   buffer is corrupted.  Any attempt to DISPLAY or LIST HISTORY
   will display graphic characters to the screen and the computer
   may freeze.





title:  SET FUNCTION, LIMIT OF 30 CHARACTERS
version:  10 11
date:  10 Mar 1986
text: 
The maximum number of characters (including semicolons) that can
be programmed into a function key is 30.  Exceeding this
limitation is not trapped as an error.  Instead, the extra
characters wrap into the next function key.  This problem will
also cause an incorrect display of the function key values in
full-screen SET.


title:  SET FORMAT TO <FILENAME>
version:  10 11 DR
date:  10 Mar 1986
text: 
Issuing an APPEND, CHANGE, EDIT, or READ command when the open
format file does not match the current database will lock the
computer.


title:  SET FILTER TO WITH GO TOP
version:  10 11 DR
date:  10 Mar 1986
text: 
After a SET FILTER TO is issued, it may be necessary to issue a
GO TOP.  Otherwise, the first record in the file may fall through
(that is, it may not be filtered out) even if it does not satisfy
the filter condition.

The commands that do not require a GO TOP are those that
automatically rewind the database file before executing (that is,
any command whose default scope is ALL).  These include AVERAGE,
COUNT, LIST, and SUM.  The commands that allow the first record
to fall through are those that have a scope of NEXT <n>.  These
include ?/??, @...SAY, BROWSE, and DISPLAY.


title:  SET FILTER TO WITH GO BOTTOM
version:  10 11 DR
date:  10 Mar 1986
text: 
If a SET FILTER TO condition is not satisfied by any records in
the database file and a GO BOTTOM is issued, both the EOF() and
BOF() will return a true (.T.).  Removing the filter by issuing a
SET FILTER TO does not reset EOF() or BOF().  The record pointer
must be repositioned to reset EOF() and BOF().  SKIP or SKIP -1,
however, will return a file boundry error message, because EOF()
and BOF() are true.  To move the record pointer appropraitely
issue a GO TOP and the BOF() and EOF() values will be reset to
false (.F.).


title:  SET EXACT ON AND INOPERABLE INDEXES
version:  10 11
date:  10 Mar 1986
text: 
SET EXACT ON will render indexes inoperable when the length of
the key expression is not a multiple of four.  SEEK and FIND
will return "No find" even if the string is in the file.  Any
attempt to access an individual record will return "Record is not
in index".  Commands that return this message are GOTO <n>, EDIT
<n>, and <n>, where <n> represents the record number.

One work-around for this is to MODIFY STRUCTURE and adjust the
length of the key field to a multiple of four.
Another work-around is to recreate the index and add spaces to
the end of the index key expression to bring it to a multiple of
four.  For example, the following index is created with the
character field, Code, of width six:
   INDEX ON Code + SPACE(2) TO Codendx
The above key expression, Code + SPACE(2), will evaluate to an
index key of eight characters which is a multiple of four.


title:  SET ESCAPE ON/OFF
version:  10 11 DR
date:  10 Mar 1986
text: 
Ctrl-S will not pause scrolling in dBASE III if ESCAPE is SET OFF.


title:  SET DELIMITERS ON
version:  10 11
date:  10 Mar 1986
text: 
If you SET DELIMITERS ON, then CREATE or MODIFY a database file
structure, pressing Esc without making any changes will SET
DELIMITERS OFF.


title:  SET CARRY ON
version:  10 11 DR
date:  10 Mar 1986
text: 
If records are added to a database file with SET CARRY ON and the
last record in the file is marked for deletion, the new records
will also be marked for deletion.  This is true for adding
records with APPEND and BROWSE.


title:  SET (FULL-SCREEN), USING THE PATH OPTION
version:  10 11
date:  10 Mar 1986
text: 
Under the Disk heading in full-screen SET, the DISK DRIVE SEARCH
PATH is used to set the internal dBASE III path.  If this path
has already been set in Config.DB or by using the dBASE SET PATH
command, the path name will show up when this option is selected.
However, when either Return or Esc is pressed at the selection,
the path name will be erased.  Therefore, if you select the Path
option and do not wish to change it, you must re-enter the path
name.  An alternate way to view the internal dBASE III path name
is to use DISPLAY STATUS.

title:  SET (FULL-SCREEN), USING THE INDEX OPTION
version:  10 11
date:  10 Mar 1986
text: 
Under the Files heading in full-screen SET, there is an option to
open INDEX files.  This option neglects to open the selected
index files when used and it will also close all active index
files in the currently selected work area.


title:  ROUND()
version:  10 11
date:  10 Mar 1986
text: 
The ROUND() function will not round negative numbers correctly.
You can use the following procedures to round off a negative
number:

          PROCEDURE Abs   {Absolute value}
          PARAMETERS inval, sign, outval
          IF inval < 0
             sign = (-1)
             outval = (-inval)
          ELSE
             sign = 1
             outval = inval
          ENDIF
          RETURN

          PROCEDURE Round   {Round a positive or negative number}
          PARAMETERS inval, outval
          sign = 1
          DO Abs WITH inval, sign, outval
          outval = sign * ( INT( ( outval * 100 ) + .5 ) / 100.00 )
          RETURN

Round is used in conjunction with Abs in rounding a number.
Round will round a number to two decimal places.  An example of
how the above procedures would be used is given below.

           * ---Assumes Math.prg contains Abs and Round.
           SET PROCEDURE TO Math
           INPUT "Enter number to round :" TO number
           result = 0.0
           DO Round WITH number, result
           ? result
           CLOSE PROCEDURE


title:  RETURN TO MASTER
version:  10 11
date:  10 Mar 1986
text: 


title:  REPORT FORM AND MODIFY REPORT
version:  10 11
date:  10 Mar 1986
text: 
(1) A REPORT FORM that is defined with a report width and a left
margin whose difference is exactly 256 causes dBASE III to
display garbage on the screen and/or printer and will require a
warm boot (that is, Ctrl-Alt-Del).  Increasing the width of the
report or decreasing the left margin so that their difference is
greater than 256 corrects this problem, but the report title will
display on several lines instead of just one.  A difference of
255 or less will properly display the report.


(2) MODIFY REPORT will allow the number of decimal places to be
changed from the default.  If this is done and the report is
run, everything is as expected.  However, if the report is
modified again, the number of decimal places reverts to the
default when the cursor reaches the "# decimal places" field.


title:  REPORT FORM WITH STACKED COLUMNS
version:  10 11 DR
date:  10 Mar 1986
text: 
CREATEing a REPORT FORM field that consists of stacked columns
built with the result of the STR() function and numeric fields
may cause numbers to display incorrectly.  Specifically,
entering:

     STR( Field1, 5 ) + STR( Field2, 5 )

in the field contents and specifying a column width of five will
result in a correct display only when the fields have five-digit
numbers stored in them.  If the number has less than five digits,
the display will be misplaced by the number of digits missing.
The example above will produce:

        11111
        11111

if the fields are full, but:

         1111
        1111
        1111

if there are only four digits in the fields.


title:  REPORT FORM WITH RIGHT MARGIN=REPORT WIDTH
version:  10 11
date:  10 Mar 1986
text: 
   CREATEing a REPORT FORM with a right margin value equal to the
report width (the page width minus the left margin) will display
garbage to the screen or printer.  This happens beacuse there is
no space to print the report.
   There is a general misconception about the meaning of the right
margin in the REPORT FORM.  Some users have the impression that
its value is the number of characters from the left margin, much
the same way a typewriter works.  The value actually refers the
the number of characters the right margin is offset from page
width.

For example,

     page width    |------------------------------------->|
     right margin                             |<----------|


title:  REPORT FORM WITH MULTIPLE LINE HEADINGS
version:  10 11
date:  10 Mar 1986
text: 
There is a problem with the REPORT FORM command in printing
multiple line headings.  Sometimes when printing a combination of
character and numeric information, the second and third lines of
the column headings get shifted to the left.  There is no known
work-around for this problem.


title:  REPORT FORM
version:  10 11 DR
date:  10 Mar 1986
text: 
(1) When using a REPORT FORM to print a Memo field that is longer
than one page, the field will print continuously on the report
with no page breaks.
[1.0, 1.1, D.R.]

(2) If the NOEJECT option of the REPORT FORM is used, and the
report does not fill the last page, the line counter is not reset
to zero.  Therefore, when the next report is printed, the first
page of this report will print an incorrect number of lines.
[1.0, 1.1, D.R.]

(3) REPORT FORMs with two levels of subtotals that use the eject
after subtotals option will format the first page of the report
differently than all other pages.  The difference is very slight,
but the first page shows the subgroup heading on the line
directly below the major group.  All other pages have a blank
line between the subgroup and the major group headings.
[1.0, 1.1]

(4) When creating a report with subtotals, answering yes to the
"Summary report only?  (Y/N)" option can cause one of two known
problems.  The REPORT FORM will either print only the contents of
the fields that are being totaled, or it will lock the system
requiring a cold boot.
[1.0, 1.1]


title:  REPLACE ALL
version:  10 11
date:  10 Mar 1986
text: 
When used without any arguments, REPLACE ALL will return the
error message "Internal error - illegal op code <no.>." The
database file currently SELECTed will not be affected.  The op
code number and the number of messages vary from machine to
machine.


title:  REPLACE IN ABBREVIATED FORM
version:  10 11
date:  10 Mar 1986
text: 
If the REPLACE command is abbreviated, (REPL, REPLA, REPLAC), or
REPLACE is used without an argument, the result may be the error
message "illegal op code <no.>." The op code number is not
relevant and varies from machine to machine.

This Developer's Release will return the message "1 record
replaced."

title:  REPLACE
version:  10 11
date:  10 Mar 1986
text: 
With SET UNIQUE ON and an index file open, if you REPLACE the key
field with a non-unique key, then REPLACE the key field again
without repositioning the record pointer, dBASE III will return
"No records replaced" and the computer will freeze.

dBASE III will also freeze the computer if SET UNIQUE is ON and
you APPEND a BLANK to an indexed file, and then do a REPLACE on
the key field.  This will occur whether or not the APPENDed
record is unique or not.


title:  RELEASE ALL
version:  10
date:  10 Mar 1986
text: 
There are instances in which the RELEASE ALL command does not
appear to work.  After executing a DO WHILE loop <n> times (the
reported instances have occurred at three iterations), the
message 'Out of memory variable memory' appears, though the
memory limits are not exceeded.  When RELEASE ALL is replaced
with CLEAR MEMORY, the problem disappears.


title:  RECORD AS A RESERVED WORD
version:  10 11 DR
date:  10 Mar 1986
text: 
Avoid using any word of the form RECORD???? as a field name,
because it can cause problems with several dBASE III commands.
Specifically, the error message "Variable cannot be found" will
occur if this field is used with either the AVERAGE, DISPLAY,
LIST, REPLACE, or SUM commands.


title:  RECNO() VALUES
version:  10 11 DR
date:  10 Mar 1986
text: 
The following section of code shows that the RECNO() function returns
the number of the last record accessed prior to closing the file.
Even if the database file is closed, RECNO() retains its last value.

    USE Names
    GOTO 7
    ? RECNO()
        7
    USE         <--- Names is closed here.
    SELECT 2
    USE Temp
    ? RECNO()
        1
    SELECT 1
    * ---SELECT 1 has no database file in USE, but
    * ---RECNO() shows the last record value of
    * ---Names before it was closed.
    ? RECNO()
        7


title:  PCOL() AND SET MARGIN TO
version:  10 11
date:  10 Mar 1986
text: 
PCOL() will not return the current printer head position when
used in conjunction with SET MARGIN TO. Instead, it returns the
current print position plus the margin offset. For example:

    STORE "Hello" TO var1
    STORE "there" to var2
    SET DEVICE TO PRINT
    @ 10,0 SAY var1
    @ PROW(),PCOL()+1 SAY var2
    SET MARGIN TO 10
    @ 11,0 SAY var1
    @ PROW(), PCOL()+1 SAY var2
    RETURN

prints the following:

           Hello there
           Hello           there


title:  PARAMETERS
version:  10 11
date:  10 Mar 1986
text: 
Misspelling the command PARAMETERS or omitting the command in a
procedure file will produce an irrelevant error message.  The error
will usually be a syntax error on a command line that looks like a
RETURN with a right arrow where the "R" should be.  This error will
also occur if an incorrect number of values are passed in the DO
<filename> WITH <parameter list> command.  For example:

* Program..: Areacalc.PRG
        PARAMATERS length,width,area
area = length * width
RETURN
* EOP: Areacalc.PRG


        * The following command is entered from the dot prompt.
DO Areacalc WITH 6,4,0

Syntax Error
 ?

A space following a memory variable in a PARAMETERS statement
will return the "Unrecognized phrase/keyword in command" error
message.  The following command sequence demonstrates this
anomaly.

* Test.PRG
         PARAMETERS name
         name = "Steve" ^-------------there is a blank
         RETURN                       space after "name".

         . mvar = "John"
         . DO test WITH mvar
Unrecognized phrase/keyword in command
?
PARAMETERS name


title:  NUMERIC ACCURACY INCONSISTENCIES
version:  10 11
date:  10 Mar 1986
text: 
There are some inconsistencies with the manner in which dBASE III
handles numeric operations, especially comparisons.  What follows
are two examples that return unexpected results.

EXAMPLE 1:

     . ? 4.1 - 2.1
      2.0
     . ? INT(4.1 - 2.1) = 2
     .F.
     . ? INT(4.1 - 2.1)
        1

EXAMPLE 2:

     . ? SQRT(100)
          10.00
     . ? SQRT(100) = 10
     .F.
     . ? INT(SQRT(100)) = 10
     .F.
     . ? INT(SQRT(100))
              9

The only reliable way to compare two numbers in dBASE III is to
use the STR() function.  For example:

     . ? STR(SQRT(100),10,2) = STR(10,10,2)
     .T.


title:  MODIFY STRUCTURE
version:  11
date:  10 Mar 1986
text: 
It has been reported that MODIFY STRUCTURE will occasionally
write a 00H in the delete marker position of a group of records
in a database file, causing those records to be shifted one
character to the right on LIST and DISPLAY.  The records will
appear normal with other commands such as EDIT and REPORT FORM.

To date, this problem has only been reported on the IBM PC AT.

If it occurs, DELETE and RECALL the offending records to restore
the delete marker to its normal state, a 20H.  (For more
information on data record structures, see page D3-15.)  For
example:

     . USE Bad_file
     . LIST

     Record#  NAME       CODE  PHONE
           1  Joe        AAA   (111)111-1111
           2   Mary       BBB   (222)222-2222
           3   Tom        CCC   (333)333-3333
           4   Alice      DDD   (444)444-4444
           5  Betty      EEE   (555)555-5555

     . GOTO 2
     . DELETE NEXT 3
           3 records deleted
     . GOTO 2
     . RECALL NEXT 3

           3 records recalled
     . LIST

     Record#  NAME       CODE  PHONE
           1  Joe        AAA   (111)111-1111
           2  Mary       BBB   (222)222-2222
           3  Tom        CCC   (333)333-3333
           4  Alice      DDD   (444)444-4444
           5  Betty      EEE   (555)555-5555


title:  MODIFY REPORT
version:  10 11
date:  10 Mar 1986
text: 
There is a problem in the REPORT FORM concerning the width of the
column.  Specifically, if a change in the field contents affects
the column width, the field width will reflect the change.
However, if the new value is not explicitly re-entered, the width
will revert to the old value when another column is accessed or
CREATE/MODIFY REPORT is exited.

The REPORT FORM in the Developer's Release has been changed to
rectify this problem.  When a field's contents are changed, the
column width will reflect the change only if the column width is
increased.  However, unlike versions 1.0  and 1.1, all changes to
the column width are saved when CREATE/MODIFY REPORT is exited.


title:  MODIFY COMMAND (DEVELOPER'S RELEASE)
version:  DR
date:  10 Mar 1986
text: 
In the Developer's Release, graphic characters will appear if you
press Ctrl-@, Ctrl-C, or PgDn on the first line of text in MODIFY
COMMAND.  These characters are easily removed by editing.


title:  MEMO FIELDS, LISTING OR PRINTING AFTER A PREVIOUS FIELD
version:  10 11 DR
date:  10 Mar 1986
text: 
A problem displaying memo fields has been found in dBASE III by
one of our users.  The problem occurs when you try to list or
print a memo field preceded by a field whose length will force
the first line of the memo field to wrap around one or more
times.
Assume a file structure consisting of two fields:


     Structure for database: Example.DBF

     Field  Field Name  Type       Width    Dec
         1  Field1      Character    100
         2  Field2      Character     70
         3  Comments    Memo          10
     ** Total **                     181

These display commands

     ? SPACE( 1 ), Comments
     ? Field1, Comments
     ? Field2, Comments
     ? Field1, Field2, Comments

will all produce different results.

If the total length of the fields preceding the memo field is 29
or above, the first line of the memo field will wrap around.  The
entire memo field will then be displayed in double space.
Futhermore, if the total length of the fields preceding the memo
field is long enough to force the first line of the memo field to
be displayed starting on the second line of the display, then the
entire memo field will be displayed in triple space.


title:  MEMO FIELDS, DISPLAYED FROM AN UNSELECTED AREA
version:  10 11 DR
date:  10 Mar 1986
text: 
An attempt to display a memo field from an unSELECTed work area will
produce the error message "Unrecognized phrase/keyword in command".
For example:

    SELECT A
    USE First
    SELECT B
    * ---The following database file has the character
    * ---field 'Name' and a memo field 'Notes'.
    USE Second
    SELECT A
    ? Second->Name   <--- This works correctly.
    *
    * ---The following line returns the error message,
    * ---"Unrecognized phrase/keyword in command".
    ? Second->Notes
    *
    * ---The following line returns,
    * ---"No database in USE, enter filename:"
    LIST Second->Notes


title:  LOAD (DEVELOPER'S RELEASE)
version:  DR
date:  10 Mar 1986
text: 
LOADable files must have filenames seven characters or less in
length.  Files having a names of eight characters will not be
LOADed correctly.
For example:

   LOAD Diskread
   CALL Diskread

will return:

   File was not LOADed.

when the CALL command is executed.  The LOAD command
produces no error message.  If the filename above is changed to
Dskread.BIN, the file is LOADed properly.


title:  LABEL LIMITATIONS
version:  10 11
date:  10 Mar 1986
text: 
Certain LABEL forms lock up the system.  This seems to happen
with forms of 13 or more lines.  Shorter forms will not print
the last few lines when these lines contain a lot of text.


title:  JOIN WITH FILES CONTAINING MEMO FIELDS
version:  10 11
date:  10 Mar 1986
text: 
The following anomalies may arise when JOINing database files
that contain memo fields.

1) JOIN will not create the .DBT file for the target database when the
active database file (that is, the file currently SELECTed) contains
the memo field. The error message, "Memo file cannot be opened" will
display when you attempt to USE the target file.

2) If the JOIN is executed with the FIELDS clause and the memo field
is omitted, the target file will display the error message, "Memo file
cannot be opened" when the target file is USEd.

3) If the file being JOINed WITH (that is, the un-SELECTed file) has a
memo field and the active file does not, a .DBT file will be created
for the target file, but the data contained in the memo field will not
be transferred.

Currently, there is no way to get the JOIN command to transfer memo
field information into the target file.  One work-around is to use the
S-Join.PRG program which simulates the JOIN command with COPY and
APPEND, and allows memo fields to be joined to the target file.
(S-Join.PRG is in the February, 1985, issue of TechNotes, page D3-7.)
If you do not want the memo fields copied
over, COPY the active database file to another file using the FIELDS
clause that does not include the memo field, USE that file, and then
execute the JOIN.


title:  INKEY()
version:  DR
date:  10 Mar 1986
text: 
The INKEY() function of the Developer's Release does not always
read the leftarrow key as CHR(19).  Running the following program
will demonstrate that dBASE III will trap this key only rarely.

     i = 0
     DO WHILE i <> 13
       i = INKEY()
       ? i
     ENDDO

When you run this program, you will notice that dBASE III treats
the leftarrow key as a Ctrl-S, and will pause or start scrolling
accordingly.  Sometimes the key will be trapped and INKEY() will
return 19; however, this is far less common than the former
result.


title:  version:  date:  text: 


title:  INDEXING WITH STR() OR SUBSTR() FUNCTIONS
version:  10 11 DR
date:  10 Mar 1986
text: 
Although the length argument of the STR() and SUBSTR() functions
is optional, it must be included when either of these functions
is used as part of an INDEX expression.  Otherwise, the error
message "Record is not in index" will occur when using either
BROWSE, EDIT or GO/GOTO.


title:  INDEX WITH SET UNIQUE ON
version:  10 11 DR
date:  10 Mar 1986
text: 
INDEXing on a numeric field with SET UNIQUE ON may produce an
incorrect count on the screen display.  The actual index file is
correct.  The counter will be correct if you INDEX use the
STR(fieldname,length).

     USE Test
     DISPLAY STRUCTURE

     Number of data records:  608
     Field, Field name, Type,   Width,    Dec
         1  One         Numeric     4       0
         2  Two         Character   5
         3  Three       Character   5
     ** Total **                   15

     SET UNIQUE ON
     INDEX ON One TO Test
          536 records indexed   *  incorrect count

     INDEX ON STR(One,4) TO Test1
          42 records indexed    *  correct count


title:  INDEX AND BLANK DATES
version:  10 11 DR
date:  10 Mar 1986
text: 
A database file that is INDEXed on a date field will put blank
dates at the bottom rather than the top of the index file.  To
work around this problem, use the following index expression
instead of the date field:

     INDEX ON STR(YEAR(Date),4) + STR(MONTH(Date),2);
            + STR(DAY(Date),2) TO <filename>

Using this expression, you will also be able to INDEX on date and
character fields simultaneously.  For example:

     INDEX ON STR(YEAR(Date),4) + STR(MONTH(Date),2);
            + STR(DAY(Date),2) + Last_name TO <filename>

This command will create an index file that is in chronological
order by Date and in alphabetical order by Last_name.


title:  FIND &MEMVAR WITH TRAILING BLANKS
version:  10 11
date:  10 Mar 1986
text: 
FIND &memvar will return "No find" if there are trailing spaces
following the memory variable.  This occurs if the FIND is in a
command file or issued at the dot prompt.  Trailing blanks are
concatenated to a macro when the FIND command is used.  With the
additional trailing blanks, the new character string might not be
found.  The following example uses a data file with the field
NAME-C-10, indexed on this field, and a record with "RALPHxxxxx"
in the Name field.  The character "x" represents a blank.

     STORE "RALPH" TO memvar
     FIND &memvar<cr>              (This FINDs record 1)
     FIND &memvarx<cr>             (Still OK - "RALPHx"is record 1)
     FIND &memvarxxxxxx<cr>        (No find - 6 trailing blanks
                                   exceeds field width)

If less than the entire string is searched for, FIND will never
work with the trailing blank.  For example:

     STORE "RAL" TO memvar
     FIND &memvar<cr>              (This finds record 1)
     FIND &memvarx<cr>             (No find - "RALx" is not in
                                   the file)

The workaround is to use the SEEK command.  For example,

     SEEK memvar


title:  EXPONENTIATION DISPLAY
version:  10 11 DR
date:  10 Mar 1986
text: 
When raising an expression to a power in dBASE III, an overflow
condition will arise if both the exponent and the expression are
literal numbers greater than or equal to 10.  For example:

     . ? 10^10
     *************

To work around this problem, STORE either the expression or the
exponent to a memory variable.  For example:

     . num = 10
     . ? 10^num
              10000000000.00


title:  EJECT AND SET PRINT ON WITH PRINTER OFF-LINE
version:  10 11 DR
date:  10 Mar 1986
text: 
EJECT and SET PRINT ON may lock the computer if the printer is not
activated.  The dBASE III User Manual warns that this may happen in
the command section under both of these commands.

If the printer power is on but the printer is off-line, issuing a
<command> TO PRINT will give the following error message:

    Write fault error writing device PRN
    Abort, Retry, Ignore?

This is an MS-DOS error message.  Therefore, if you Abort, you will
leave dBASE III and be left at the operating system level.  The proper
way to recover is to put the printer on-line and then Retry.

title:  EDIT
version:  10 11 DR
date:  10 Mar 1986
text: 
If BROWSE is used on an indexed file and is terminated with a
Ctrl-Q or Ctrl-W and followed with an EDIT command, keys which
advance or regress through the database file (PgUp,
PgDn, uparrow, downarrow, Ctrl-E, Ctrl-R, Ctrl-C) will not work
properly.

Sometimes these keys will drop the user out of EDIT to the dot
prompt.  Other times they will move two or three records instead
of one.  The display will sometimes lock on the current record.
These keys may also cause the pointer to be positioned at
the next to last record in the index.


title:  DO WHILE WITH AN EXTRA ENDDO
version:  10
date:  10 Mar 1986
text: 
If an extra ENDDO is added to a command file, an infinite loop
will result.  For example, the following program will execute
until Esc is pressed:

        number = 0
        DO WHILE number < 10
           @ 10,10 SAY "Now at loop " + STR(number,2)
           STORE number + 1 TO number
        ENDDO
        ENDDO           <--- This ENDDO has no matching DO WHILE.
        RETURN

We recommend you use some method of indentation for the control
structures: DO CASE...ENDCASE, DO WHILE...ENDDO, and IF...ENDIF
to avoid this problem.  This practice will make command files
more readable, and will allow for quick visual checking for
accuracy of nested control structures.  In our example, two
consecutive ENDDO statements with the same left margin is a
definite indication that something is wrong.

When using the command DISPLAY OFF in conjunction with TO PRINT
and no specified scope in a command file, the DISPLAY will have
an extra line-feed between each line.  For example:

SET HEADING OFF
DO WHILE .NOT. EOF()
   DISPLAY OFF <Field1>, <Field2> TO PRINT
   SKIP
ENDDO

will yield:

<value1> <value2>
                        <----------- extra line-feed
<value1> <value2>          |
                   <-------
<value1> <value2>


title:  DO WHILE WITH RETURN
version:  10 11 DR
date:  10 Mar 1986
text: 
A RETURN statement inside a DO WHILE...ENDDO construction will
not close the DO WHILE <condition> in the program as it does in
dBASE II.  Therefore, the <condition> will continue to be
evaluated.  For example:

     * A.PRG
     expA = "1"
     DO WHILE expA = "1"
        ? "Hi!"
        DO B     --------------->  * B.PRG
     ENDDO                         expB = "2"
     * EOF: A.PRG                  DO WHILE expB = "2"
                                      ? "How are you?"
                                      expA = "X"
                                      RETURN
                                   ENDDO
                                   * EOF: B.PRG

Executing A.PRG will cause an infinite loop.  It appears dBASE
III continues to test the condition of expB.  In order to work
around this, B.PRG should be written as follows:

          * B.PRG (revised).
          expB = "2"
          DO WHILE expB = "2"
             ? "How are you?"
             expA = "X"
             EXIT             <----- Notice, the EXIT here,
          ENDDO
          RETURN              <----- and the RETURN here.
          * EOF: B.PRG


title:  DO WHILE WITH SEMICOLON
version:  10 11
date:  10 Mar 1986
text: 
When a DO WHILE conditional statement is continued to a second
line with a semicolon, dBASE III tries to execute this second
line the second time through the loop.  When the ENDDO is
encountered and the condition evaluates as true, program flow
proceeds to this second line, resulting in the error message,

"*** Unrecognized command verb."  For example:

          * ---This program will give an error message
          * ---when "Y" is entered at the WAIT prompt.
          answer = 'Y'
          number = 1
          DO WHILE number < 10;
             .AND. answer = 'Y'
             ? number
             WAIT '"Y" to continue ' TO answer
             number = number + 1
          ENDDO

If "Y" is entered at the WAIT prompt, dBASE III tries to execute
".AND. answer = 'Y'."  However, if the semicolon is deleted and
the line is allowed to wrap at column 67 in MODIFY COMMAND,
execution flows correctly.


title:  DO WHILE WITH RESTORE
version:  10 11 DR
date:  10 Mar 1986
text: 
If a memory variable tested in a DO WHILE loop is recreated in
the loop by RESTOREing the variable FROM a memory file, the loop
will continue to run even after the condition no longer evaluates
as true (.T.).  The program below will run endlessly as long as
the control variable is not the first entry in the memory file:

     var = .T.
     DO WHILE var
        RESTORE FROM Memfile <--- This overwrites var at the
                                  same memory location.
        var = .F.            <--- This change is ignored if
     ENDDO                        the previous assignment
                                  statement changed the
                                  memory location of the
                                  variable.

RESTOREing ADDITIVE ameliorates the problem.


title:  DO COMMAND FILE IN PROCEDURE ON TI PROFESSIONAL
version:  11
date:  10 Mar 1986
text: 
With a procedure file open, attempting to DO  any command file
will result in a "*** Syntax error ***."  For example,
the command file below will produce the error.

     SET PROCEDURE TO Test1
     DO Routine <---------------- Routine is a procedure
     DO Nonproc <-------------|   in Test1.
     RETURN                   |
                              |-- This is a separate
                                  command file.

DO Routine will execute; however, DO Nonproc will produce  the
error message.  This problem has been reported on the TI PRO
version of dBASE III only.  This will not produce an error on the
IBM PC version.


title:  CTOD()
version:  10 11
date:  10 Mar 1986
text: 
If a date type memory variable is created with a blank date and
the month contains less than two spaces, the result will be
11/30/99.  This occurs only if the month positions are incorrect.
If the day and year positions are incorrectly initialized, the
result is the expected,   /  /  .

Month position incorrect:

    date = CTOD(" / / ")
                 ^             One space instead of two.
The result:   11/30/99

Day and year positions incorrect:

   date = CTOD("  //")

The result:     /  /


title:  CREATE AND ALIAS
version:  10 11
date:  10 Mar 1986
text: 
After you CREATE a file, you must USE it again in order to
establish the file name as the default alias name.  Otherwise,
the file name will have no alias name assigned to it.  For
example:

     CREATE File_one
     * ---Enter file structure.
     * ---Add a few records.
     DISPLAY STATUS
     * ---No alias name appears.
     SELECT 2
     USE New_file
     SELECT File_one
     * ---Gives "Alias not found" message.


title:  CREATE <FILENAME>
version:  10 11 DR
date:  10 Mar 1986
text: 
(1) In dBASE III, a legitimate file name may contain up to eight
characters consisting of an initial letter, and any combination
of letters, numbers, and underscores.  However, special
characters ($,#,-,@,+,etc.) in the name will cause an error
message if an <Alias> -> <Fieldname> is used.  For example:

     USE Names
     SELECT 2
     USE Test-it
     SELECT Names
     ? Test-it -> Fieldname
     Variable not found
            ?
     ? Test-it -> Fieldname

(2) When creating a database file, if <RETURN> is pressed in the
first field of the screen and editing is then resumed by pressing
any key other than <RETURN>, the structure of the file saved will
be corrupted.  LISTing the STRUCTURE may lock the machine.
[1.0, 1.1]


title:  COPY TO <FILENAME> SDF
version:  10 11
date:  10 Mar 1986
text: 
If the database file being copied has a MEMO field, the data in
the fields following the MEMO field will either not be copied or
will be copied incorrectly.

To work around this problem, use the FIELDS phrase in the COPY
command.  For example:

      COPY TO <filename> FIELDS <field list> SDF


title:  COPY TO <FILENAME> DELIMITED WITH WITHOUT DELIMITER
version:  10 11
date:  10 Mar 1986
text: 
Using COPY TO <filename> DELIMITED WITH without a delimiter is
not trapped as an error and will cause one of two problems: (1)
if there is a space after the WITH, the error "Unrecognized
phrase/keyword in command" is displayed; (2) if there is no
space, the file is copied but the target file will contain all
blank records.
   This problem was discovered in an attempt to build a comma
separated file in which the character strings were not enclosed
in delimiters.  Currently, the COPY command does not have this
capability.  You can, however, create a comma separated file in
which the character strings are delimited with a blank.  The
syntax is:

          COPY TO <filename> DELIMITED WITH BLANK


title:  COPY TO <FILENAME> DELIMITED
version:  10 11
date:  10 Mar 1986
text: 
If a database file structure contains a large number of character or
numeric fields with a length of one, the COPY TO <filename>
DELIMITED command will produce unreliable results.  For example, a
file with 29 one-character fields will produce a text file with the
following record:

     1,"A","A","A",1,1,"A","A","A","A","A",1,1,1,1,1,1/
     ,"A","A","A",",",",,,",","

The last fields in the record have been garbled.


title:  COPY [STRUCTURE] TO <FILENAME> WITH SET SAFETY
version:  10 11
date:  10 Mar 1986
text: 
The COPY [STRUCTURE] TO <filename> command ignores the status of
SET SAFETY if it is issued in a command file.  It will overwrite
the target database file without warning.  There are two
work-arounds for this problem.  The first work-around is to use
the COPY FILE command instead.  You will have to CLOSE the source
database before this command can be used.  The other work-around
is to use the FILE() function to check for the existence of the
target file before issuing the COPY TO command.  For example:

    overwrite = .F.
    IF FILE( "Temp.DBF" )
        @ 10,0 SAY "File already exists, overwrite it?  (Y/N)";
        GET overwrite
        READ
    ELSE
        overwrite = .T.
    ENDIF
    IF overwrite
        COPY TO Temp
    ENDIF


title:  CONFIG.DB WITH TEDIT OR WP
version:  10 11
date:  10 Mar 1986
text: 
Config.db will not accept more than eight characters for WP
or TEDIT.  Any more than eight will be truncated.  Attempting to
use MODIFY COMMAND (or to edit a MEMO field) will briefly display
the operating system message "Bad command or file name" and drop
the user to the dBASE dot prompt (or to the edit screen).  dBASE
III warns the user that the filename is truncated when dBASE is
initialized.  For example:

     TEDIT=B:DFORMAT
                    ^--- truncated

To work around this problem, place the word processor in the same
drive and directory or rename the wordprocessor with fewer
characters.


title:  CONFIG.DB WITH SCOREBOARD
version:  10 11
date:  10 Mar 1986
text: 
The entry SCOREBOARD=OFF has no effect if set in CONFIG.DB.
SETing the SCOREBOARD OFF suppresses the display of status and
error messages to line 0 .  The SCOREBOARD setting can only be
changed from a command file or the dot prompt with the command
SET SCOREBOARD OFF.


title:  CLOSE PROCEDURE
version:  10 11 DR
date:  10 Mar 1986
text: 
If CLOSE PROCEDURE is included inside a procedure file, the
procedure will stop running.  The correct place to include the
CLOSE PROCEDURE command is inside the calling program.


title:  CTRL-C WHILE PRINTING
version:  10 11
date:  10 Mar 1986
text: 
If Ctrl-C is pressed while dBASE III is printing, the user is returned
to the operating system.  LIST TO PRINT, DISPLAY TO PRINT, and
operations performed with SET PRINT ON and REPORT FORM TO PRINT are
affected in this way.


title:  BROWSE
version:  10 11
date:  10 Mar 1986
text: 
It appears that dBASE III does not release the memory used by
BROWSE when the command is terminated.  As a result, using many
consecutive BROWSE commands will cause dBASE III to run out of
memory and display the error message "Insufficient memory."  The
exact number will depend on how much memory is available.  Once
the error message occurs, the only way around the problem is to
QUIT out of dBASE.  CLEAR MEMORY will not solve the problem.


title:  BROWSE, APPENDING IN
version:  10 11 DR
date:  10 Mar 1986
text: 
Records seem to disappear when you use the APPEND option in BROWSE.  To see
this, go into BROWSE, then add a record, butdo not fill in all of the fields.
The record number of the status line will be <n>.  Press PgDn to add another
record.  The record previously added disappears and the record number will be
one less than the previous number.  Fill in some of the fields again, but this
time press Return through therest of the fields.Check the record number, then
press the Up Arrow key, then PgDn, and the missing record reappears with the
proper record number restored.


title:  AVERAGE PRODUCES LINEFEEDS
version:  10 11
date:  10 Mar 1986
text: 
See SUM.


title:  ASSIST WITH EXACTLY 27 FIELDS
version:  10 11
date:  10 Mar 1986
text: 
Choosing an option in ASSIST that allows a FOR/WHILE clause
(AVERAGE, DISPLAY, REPORT, etc...) on a database of exactly 27
fields, will not allow the last several fields to be used as part
of the FOR/WHILE clause if the down arrow key is used to access
those fields.  Everything will appear fine until the last group
of fields is displayed on the screen, at which point pressing the
down arrow will take you to the next menu screen.

Note that this anomaly only occurs on a database file with
exactly 27 fields.  It is possible to access the last several
fields by way of the PgDn and down arrow keys; but, it is much
easier to MODIFY the STRUCTURE of the database file to add
another field which avoids the problem altogether.


title:  ASSIST
version:  10 11
date:  10 Mar 1986
text: 
If the status of SET INTENSITY is OFF, ASSIST will be difficult
to use.  This is due to the fact that ASSIST relies on the
options being in reverse video and yet neglects to change the
status of the intensity parameter.


title:  APPEND FROM
version:  10 11 DR
date:  10 Mar 1986
text: 
(1) When using the APPEND FROM command, if the SDF file which is being
read in has a 00 hex, any data for that record which appears after the
00 hex will not be added.  If each record starts with a 00 hex,
records will be APPENDed but they will all be blank.

(2) If you APPEND FROM a DELIMITED text file that contains a space
after a numeric field and before the comma, a zero will appear in the
field following the numeric field.  The blank space is apparently read
as a separate field with a value of zero.
   Please note that Framework version 1.0 generates a text file of this
format, which will be APPENDed incorrectly by dBASE III.  Framework
version 1.1 no longer terminates numeric fields in a text file with
blanks.  Such files will be APPENDed correctly by dBASE III.
[1.0, 1.1]


title:  APPEND WITH A FORMAT FILE
version:  10 11
date:  10 Mar 1986
text: 
Attempting a full-screen APPEND with a format file that does not match
the database file will occasionally hang the computer or return the
user to the dot prompt.


title:  APPEND
version:  10 11
date:  10 Mar 1986
text: 
dBASE III allows the user to move back into previously existing
records when using the interactive APPEND.  If an index file is
in use and key fields are edited in this manner,the index is no
updated with the new key field values.  The database file will
have to be REINDEXed.


title:  APPEND (OR INSERT)
version:  10 11 DR
date:  10 Mar 1986
text: 
(1) If a file has so many fields that it requires more than one
screen during full-screen APPEND (or INSERT), pressing Return in
response to a numeric field on any screen other than the first
will not display a zero in that field.  This is strictly a
cosmetic problem that will manifest itself only in the
full-screen mode.  That is, if you use CHANGE or EDIT, the field
will appear blank, but ?, DISPLAY, and LIST will display the
field as a zero.

(2) When using full-screen APPEND (or INSERT), issuing a Ctrl-W
or a Ctrl-End in the first character of a blank record will write
the record to the file before leaving the full-screen mode.  This
is inconsistent with the original version (1.00) of the product.

To work around this problem, use either Return, Ctrl-Q, or Esc to
exit the full-screen mode.


title:  ADDITION
version:  10 11
date:  10 Mar 1986
text: 
Adding 50 or more numbers together in a single command line will lock the
computer, requiring a cold boot.  For example, the command ?  1+1+1...+N,
where N is the 50th number, will produce the correct answer, then freeze the
computer.


title:  ?? COMMAND
version:  10 11
date:  10 Mar 1986
text: 
Outputting a memo field with the ?? command in a program
may produce undesirable results.  The first time the command
is encountered, the memo field will display correctly.
Thereafter, only the first line of the memo field will
display correctly.  All subsequent lines will be offset to
the right.  For example, this program:

           DO WHILE .NOT. EOF()
              USE Test
              ?? Memo_fld
              SKIP
           ENDDO

will output:

The first memo field that prints will print out
        correctly.

        The second memo field will display like this if there
                            is more than one line.

                            ^---------The second and subsequent
                                      lines are displaced.


title:  & FUNCTION
version:  10 11 DR
date:  10 Mar 1986
text: 
The macro (&) function  will not expand properly if it is
followed by a space and parentheses.  For example:


     STORE 'LIST FOR' TO x
     STORE 10 TO memvar
     &x Field1 = memvar


will execute properly, but,

     &x (Field1 - memvar) * memvar = 0

will return the "*** Unrecognized command verb" error message.
This problem can be avoided by terminating the macro-substituted
memory variable with a period.  For example,

     &x. (Field1 - memvar) * memvar = 0

will work.  It is always a good idea to terminate a macro with a
period.


title:  @...SAY...PICTURE "@Z"
version:  10 11
date:  10 Mar 1986
text: 
The zero-suppress function, @Z, will not suppress the decimal
point when it is used with a non-integer value of zero.  To work
around this display problem, use the following command sequence
instead of the @Z function.

         IF STR( number, 5, 2 ) <> " 0.00"
            @ 10,0 SAY number
         ENDIF

title:  @...SAY...PICTURE LOGICAL VARIABLE
version:  10 11 DR
date:  10 Mar 1986
text: 
   There is no PICTURE clause that applies to a logical variable
in an @...GET command.  However, if you attempt to use a PICTURE
clause on a logical field or memory variable, dBASE III will not
trap it as an error.  When the READ is executed, dBASE III will
not pause for user input, and the value of the field or variable
will not be changed.
   One possible occurrence of this is when a memory variable is
declared PUBLIC but is not initialized before an @...GET command.
(dBASE III will automatically initialize a PUBLIC memory variable
to a logical .F.)  If the variable was not intended to be a
logical variable, the above symptoms will manifest themselves.
You may want to use the SPACE() function to initialize character
variables and zero to initialize numeric variables.


title:  @...SAY...PICTURE "@A" AND "@!"
version:  10 11 DR
date:  10 Mar 1986
text: 
The A and ! PICTURE clause functions are mutually exclusive.
That is, you cannot combine the two to make a new function that
will limit data input to alphabetic characters and force the
letters to uppercase.  If A and ! are used together, only the
second function will be in effect.  For example:

     PICTURE "@A!"  is equivalent to   PICTURE "@!"
     PICTURE "@!A"  is equivalent to   PICTURE "@A"


title:  @...SAY...PICTURE "@X" AND "@C"
version:  10 11 DR
date:  10 Mar 1986
text: 
The C and X functions documented in the manual reference to
the @...SAY command will always display positive numbers as
credits (CR) and negative numbers as debits (DB).  Use the
following program segment if you need them to display in the
reverse order (that is, positive numbers as debits (DB) and
negative numbers as credits (CR)):

     DO CASE
        CASE number > 0
           @ row,col SAY STR(number,17,2) + "DB"
        CASE number < 0
           @ row,col SAY STR(-number,17,2) + "CR"
        OTHERWISE
           @ row,col SAY STR(number,17,2)
     ENDCASE


title:  @...SAY...PICTURE "$", ",", AND "9"
version:  10 11 DR
date:  10 Mar 1986
text: 
Using the template symbols "$", ",", and "9" in an @...SAY
PICTURE clause may cause more than one dollar sign to be
displayed on the screen.  Specifically, if the value being
displayed does not fill positions in the display string preceding
the comma position, a dollar sign will be displayed in place of
the comma.

For example:

     mem = 123456
     @ 10,0 SAY mem PICTURE "$999,999,999"
     @ 11,0 SAY mem PICTURE "$999,999,999,999"

will output:

     $   $123,456
     $   $   $123,456

The PICTURE template, ($), is intended to replace leading zeros
in a numeric display with dollar signs.  This means that  dollar
signs should always display in a fixed position format.  To
display a fixed position dollar sign leading a numeric expression
with embedded commas, use two @...SAY commands, one to display
the dollar sign and the other to display the numeric variable
with the embedded commas.  For example,

     mem = 1234.56
     @ 10,10 SAY "$"
     @ ROW(),COL() + 1 SAY mem PICTURE "99,999.99"

If you wish a leading dollar sign that is floating for numeric
variables with embedded commas, a feature not directly supported
by dBASE III, use the following command file to format the
numeric variables.

     * Commas.PRG
     PARAMETERS mem
     mvar = SUBSTR( STR( mem, 9, 2 ), 1, 3 ) + ",";
          + SUBSTR( STR( mem, 9, 2 ), 4, 3 );
          + SUBSTR( STR( mem, 9, 2 ), 7, 3 )
     cntr = 1
     DO WHILE SUBSTR( mvar, cntr, 1 ) $ ", "
        cntr = cntr + 1
     ENDDO
     cnum = SPACE( cntr - 1 ) + "$" + SUBSTR( mvar, cntr )
     @ 10,0 SAY cnum
     * EOP Commas.PRG

     STORE 1234.56 TO x
     DO Commas WITH x

outputs:

     $1,234.56

This formula will work with numbers as large as $999,999.99.
Larger numbers require that the length argument of the STR()
function and the length and starting point arguments of the
SUBSTR() function be changed to accommodate the larger number.
For numbers as large as $999,999,999.99 the second line of the
preceding program should be changed to:

     mvar = SUBSTR( STR( mem, 12, 2 ), 1, 3 ) + ",";
          + SUBSTR( STR( mem, 12, 2 ), 4, 3 ) + "," ;
          + SUBSTR( STR( mem, 12, 2 ), 7, 3 ) +;
            SUBSTR( STR( mem, 12, 2 ), 10, 2 )

This problem persists in the Developer's Release including both
the PICTURE clause and the TRANSFORM() function.  The
work-arounds are a little bit easier given some new functions
including TRANSFORM() itself.  To display a numeric expression
with a leading dollar sign in fixed position and embedded commas
concatenate a dollar sign to the result of the TRANSFORM() of the
numeric expression.  For example,

     mem = 1234.56
     @ 10,10 SAY "$" + TRANSFORM( mem, "99,999.99" )

To display a floating dollar sign leading a numeric expression
with embedded commas, insert the dollar sign into the result of
the TRANSFORM() function on the numeric expression.  For example,

     mem = 1234.56
     @ 10,10 SAY SPACE(10-LEN(LTRIM(TRANSFORM(mem,"99,999.99"))));
                        ^--------- Length of the TRANSFORM() picture.

                 + "$" + TRANSFORM(mem,"99,999.99")

It is important to note that the first element in the SPACE()
function argument must be the length of the TRANSFORM() picture.  If,
for example, the picture is "999", then the element is three.


title:  @...SAY...PICTURE "@("
version:  10 11 DR
date:  10 Mar 1986
text: 
Displaying negative numeric memory variables with the @...SAY
command and the PICTURE function "@(" to enclose negative numbers
in parentheses, will not display the PICTURE correctly.  Blanks
will display between the beginning parenthesis and the memory
variable contents.  For example:

     number = 23.15
     @ 10,10 SAY number PICTURE "@("

     (      23.15)

The workaround is as follows:

     STORE STR( number, 12, 2 ) TO mem1
                         ^------------ Use an appropriate length
                                       and decimal value.
     STORE AT( "-", mem1 ) TO mpos
     @ 10,10 SAY SPACE(mpos-1) + "(" + SUBSTR(mem1,mpos+1)  + ")"

     (23.15)


title:  @...SAY...GET
version:  10 11 DR
date:  10 Mar 1986
text: 
   When entering numbers to the right of the decimal place of
numeric fields, typing the period will sometimes cause the cursor
to jump back to the beginning of the field.  This problem
manifests itself only when using a database file with one or more
index files.  The problem will also occur using APPEND, BROWSE,
CHANGE, and EDIT.
   There are numerous work-arounds for this anomaly, but not all of
them work all of the time.  First, try reducing the number of
buffers used in Config.sys to between 12 and 15.  If this doesn't
solve the problem and you are using an Autoexec.bat file, try
removing the batch file from your boot disk.  Finally, if there
is a DEVICE=ANSI.SYS entry in Config.sys, try removing the entry.
Note: You will need to reboot the machine in order for any of
these changes to take effect.
   If text is printed to the screen with @...SAY, and then an
@...SAY...GET is printed to the same line without erasing it first,
characters from the previous text will appear between the SAY and
the GET.  For example:

     STORE '123' TO mem
     @ 10,0 SAY 'XXXXXXXXXXXX'
     @ 10,0 SAY 'A' GET mem

displays:

     AX123XXXXXXX
      ^---------------- This should not be displayed.

   If you attempt to do a GET at a location greater than or
equal to 80, the error message "SAY/GET position is off the
screen" will be displayed.  However, if you issue an
@...SAY...GET that places the first character of the GET field in
column 80, the machine will lock, requiring a warm boot.  For
example:

        STORE 'TEST' TO test
        @ 10,78 SAY 'x' GET test

Note that this problem occurs only in this one instance.  If the
column coordinate in the above example is changed to 79, no error
message is displayed and the GET wraps around to the next line on
the screen.


title:  @...GET ALIAS IN FORMAT FILE
version:  10 11 DR
date:  10 Mar 1986
text: 
Any command that allows editing of a record will only
operate in the SELECTed work area.  However, attempting an
@...SAY...GET using an ALIAS or SELECT to access another work
area in a format (.FMT) file will not produce an error message.
Instead, the entire line is suppressed, including the SAY
statement.  The Developer's Release of dBASE III will return the
"Variable not found" error message if any attempt is made to GET
a field from another work area.  In versions 1.0 and 1.1 of dBASE
III, the command:

     @ 10,4 SAY "Testing " GET B->Test

in a format file will not display anything on the screen.
Issuing this command from the dot prompt or in a command file
will return "Variable not found."  An alias name is acceptable in
a SAY statement, even in a format file.

     @ 10,4 SAY "Testing " + B->Test

will display properly.

Notice that in the first example neither the SAY nor the GET
pertaining to the second work area are displayed.



108 item(s) found