home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Shareware Overload
/
ShartewareOverload.cdr
/
database
/
db3tips2.zip
/
ATDB3NTS.TXT
next >
Wrap
Text File
|
1986-07-01
|
68KB
|
1,933 lines
Ashton-Tate dBASE III Reference Notes
These dBASE III Reference Notes were obtained from the Ashton-Tate
Support Library on CompuServe (GO ASHTON).
Steve Mullen [71676,124]
Menu 1
>>> @...GET...RANGE
RANGE is used in conjunction with @...GET to specify an acceptable
continuous set of input values to date or numeric fields. The RANGE is
initialized by specifying lower and upper bounds (inclusive) which may
be literal values, memory variables, or expressions. For example:
1) Literal values:
@ 10,10 GETvar1 RANGE 1,9
@ 11,10 GET mdate RANGE CTOD('12/12/84'),CTOD('12/12/85')
2) Memory variables:
STORE 1 TO low
STORE 9 TO high
@ 10,10 GET var1 RANGE low,high
STORE CTOD('12/12/84') TO low_date
STORE CTOD('12/12/85') TO high_date
@ 10,10 GET mdate RANGE low_date,high_date
3) Expressions:
@ 10,10 GET var1 RANGE low+365,high+(365*10)
@ 11,10 GET mdate RANGE DATE(),high_date+120
Entries outside of the defined range will generate an error message and
input will be prompted until a valid entry is made.
>>> @...GET and READ
(1) If an attempt is made to @...GET memvar PICTURE "999.99" and
the memory variable is not initialized with the number of decimal
places specified in the PICTURE clause, the GET display will not show
the decimal digits for input. Entering a decimal point will exit the
GET. For example:
* ---Set up numeric input.
num = 0
@ 10,10 SAY "Enter number " GET num PICTURE "999.99"
READ
*
* ---After entering a decimal point during the READ,
* ---the GET will display the following:
Enter number : 0. :
To properly input numeric memory variables with decimal digits using
@...GET...PICTURE, initialize the memory variable with the number of
decimal digits used in the PICTURE clause. For example:
* ---The following command line assigns num with
* ---the same number of decimal digits as found
* ---in the PICTURE clause.
num = 0.00
@ 10,10 SAY "Enter number " GET num PICTURE "999.99"
READ
(2) When using @...GET and READ cetain keys will terminate the READ.
The following table shows which keys do so and where in the pending
GETs the key will terminate the READ.
Key: The READ will terminate at:
----------- ---------------------------
Backspace First character of first GET
Left arrow First character of first GET
Right arrow Last character of last GET
Up arrow First GET
Down arrow Last GET
Esc Anywhere
F1 Anywhere
Ctrl-[ Anywhere
Ctrl-Q Anywhere
Ctrl-W Anywhere
Ctrl-Home Anywhere
Ctrl-End Anywhere
PgUp Anywhere
PgDn Anywhere
Ctrl-PgUp Anywhere
Ctrl-PgDn Anywhere
Alt 0-9 Anywhere
>>> @...GET...PICTURE
Assuming a memvar is initialized with zero (that is, memvar = 0), when
the user types a period at an @...GET memvar PICTURE "9999.99", dBASE
will proceed to the next command line. This will not occur when the
memory variable is initialized to two decimal places (that is, memvar =
0.00). Only the integer portion of the number just entered will be
stored to memvar if the period is typed.
>>> @...GET...PICTURE
The function "@B" is used with the @...SAY...GET statement to
left-justify variables of numeric type. It is most useful when SAYing
a numeric field or memory variable that is more easily understood as a
character string, such as a part number. Use of this FUNCTION with GET,
however, causes a slight change in the way numeric variables are read
from the screen that may cause some difficulties.
A numeric memory variable will default to a length of ten digits
when initialized; however, if you are using the PICTURE function "@B"
in an @...GET statement, a numeric memory variable will GET the width
of the memory variable exactly as initialized, even if a template
symbol is used. Initializing a memory variable to zero will cause the
GET statement to display one zero on the screen. A READ command will
allow one digit only to be entered to the memory variable. This occurs
whether the memory variable is initialized to 0 or 0000. For example:
SET DELIMITERS ON
w = 1234
x = 0
y = 0000
@ 9,0 GET w PICTURE "@B9999"
@ 10,0 GET x PICTURE "@B9999"
@ 11,0 GET y PICTURE "@B9999"
will produce:
:1234:
:0:
:0:
A READ command will allow four characters to be entered in the first
variable, but only one character in the next two variables. If the "@B"
function is used, initialize the memory variable to the proper length
or the input may be truncated.
>>> @...SAY...PICTURE
To display a dollar-sign character ("$") in front of a numeric
value and not have the possibility of a lot of "$"s filling the blank
areas, do the following:
* ---To display a single "$".
STORE 123.56 TO num
@ 10,10 SAY "$"
@ 10,11 SAY num PICTURE "99,999.99"
This will generate:
$ 123.56
* ---The other option available is:
STORE 123.56 TO num
@ 10,10 SAY num PICTURE "$$,$$$.$$"
This will generate:
$$$123.56
>>> @...SAY using relative addressing
We use the '$' function in dBASE II to control relative screen
addressing with the @...SAY function. For example, you can have a
command file print the contents of a datafile to the screen as follows:
* ---This is dBASE II syntax.
USE <datafile>
DO WHILE .NOT. EOF
*
@ 5, 5 SAY <Field1>
@ $+1,$ SAY <Field2>
@ $+1,$ SAY <Field3>
@ $+1,$ SAY <Field4>
SKIP
*
ENDDO [while .not. eof]
The dBASE III utility, dCONVERT, is used to convert dBASE II
programs, datafiles, etc. to dBASE III formats. dCONVERT does not
change the '$' function to ROW() and COL(); it leaves it alone.
However, this will not cause any problems when executing the code in
dBASE III. dBASE III will treat the '$' function as a relative
addressing function.
>>> APPEND FROM <filename> [SDF/DELIMITED [WITH <delimiter>]]
The DELIMITED form of the APPEND FROM command should be documented
as having a WITH clause. WITH is not mentioned in the reference
section. Below are a few examples:
Example 1. To read a comma delimited file in which the character
strings are enclosed in double quotes:
APPEND FROM <filename> DELIMITED
or
APPEND FROM <filename> DELIMITED WITH "
Example 2. To read a comma delimited file in which the character
strings are enclosed in single quotes:
APPEND FROM <filename> DELIMITED WITH '
Example 3. To read a comma delimited file in which the character
strings are not enclosed at all:
dBASE III CANNOT READ A FILE OF THIS FORMT!
Also, the syntax of the APPEND command does not include a WHILE
option as the manual indicates. The correct syntax is:
APPEND FROM <file name> [FOR <condition>]
[SDF/DELIMITED [WITH <delimiter>]]
APPEND FROM <textfile> SDF expects records in the text file to be
terminated with a carriage return/line feed (0DH 0AH) pair, in this
order. If the order is reversed (0AH 0DH), dBASE III ignores the
character following the carriage return. This causes the first
character of every record (after the first record) to be missed in the
resultant database file.
Menu 2
>>> Closing Database Files
Do not swap data disks without first closing all the open files on
the original disk. Not doing so will cause the loss of data in buffers,
and will also write a new entry in the directory of the new disk. USE
will close the currently SELECTed database file and CLOSE DATABASES
will close all database files in all work areas. CLEAR ALL also closes
all open database files and will also release all memory variables.
QUIT closes all files, releases all variables, and exits dBASE III.
Choose one of these commands to close your files before swapping data
disks.
>>> COPY TO <filename> [SDF/DELIMITED [WITH <delimiter>]]
(1) COPY TO <filename> DELIMITED does not enclose logical fields
with the specified delimiters. Numeric and date fields are also
treated this way. Date fields go out in the format YYYYMMDD.
(2) COPY TO <filename> DELIMITED WITH , encloses the character
fields in commas and separates the fields with another comma. This
command behaves differently from dBASE II as shown below:
In dBASE II:
. USE file1
. COPY TO file2 DELIMITED WITH ,
will result in:
SANTA,CLAUS,NORTH POLE,ALASKA
In dBASE III:
. USE file1
. COPY TO file2 DELIMITED WITH ,
will result in:
,SANTA,,,CLAUS,,,NORTH POLE,,,ALASKA,
>>> COPY FILE <source filename> TO <target filename>
The COPY FILE command copies files in 512-byte blocks whereas the
COPY TO command will copy a .DBF file until the end-of-file. Therefore,
the COPY FILE command will usually create a slightly larger file than
the COPY TO command. However, the COPY FILE is faster.
>>> COPY STRUCTURE EXTENDED
CREATE FROM
COPY STRUCTURE EXTENDED and CREATE FROM are fully implemented in
dBASE III although not documented. A brief description is given below.
1) COPY STRUCTURE EXTENDED creates a file in whch the field names
become the contents of one record. The syntax for this COPY option is:
COPY STRUCTURE EXTENDED TO <new file>
2) CREATE FROM forms a new database (.DBF) file in which the
structure is determined by the contents of a file created with COPY
STRUCTURE EXTENDED. The syntax is:
CREATE <new file> FROM <structure extended file>
>>> CREATE/MODIFY REPORT
When you get the error message "Internal error - bucket overfilled"
while in CREATE REPORT or MODIFY REPORT, you have too many characters in
the report. The maximum number of characters, or bucket size, is 1,440
bytes. This includes the number of characters in the following list:
Report heading - plus one byte for each line
Subtotal heading(s) - plus one byte for each line
Subtotal expression(s) - plus one byte for each expression
Field heading(s) - plus one byte for each line
Field expression(s) - plus one byte for each expression
The extra byte is a null terminator for each expression and
heading. When there are multiple lines in a heading, dBASE III
separates them with a semicolon in the .FRM file.
>>> Date conversion from dBASE II
The dBASE BRIDGE manual (pages 23-24) lays out an elaborate scheme
for converting dBASE II "dates" to dBASE III date fields. A much easier
way is to simply convert the dBASE II database file to a dBASE III file
and modify the structure from character to date field. All dates stored
in a dBASE II character field as "MM/DD/YY" will directly convert to a
dBASE III date field.
>>> Dates that are blank
CTOD() and DTOC() are intended to be inverse functions. That is,
if DTOC(date) = char, then CTOD(char) = date. This is true in all
circumstances except when the date is blank and the character string is
" / / ". To detect a blank date, you must use the DTOC() function
rather than CTOD(). For example:
reg_date = CTOD("11/09/84")
? reg_date = CTOD("11/09/84")
.T.
? DTOC(reg_date) = "11/09/84"
.T.
* ---With a blank date the following occurs:
blank_date = CTOD(" / / ")
? blank_date = CTOD(" / / ")
.F.
? DTOC(blank_date) = " / / "
.T.
As is evident from the example, the blank date is handled differently
than the non-blank date.
>>> Debugging tip
The RETURN and CANCEL commands will release all PRIVATE memory
variables when returning to the dot prompt. This can make debugging
difficult with versions 1.0 and 1.1 as you may want to check the status
of variables used by the program. The following debugging utility can
be set up as a command file. This utility, called Dot.PRG, will allow
you to interactively enter commands, such as LIST MEMORY and LIST
STATUS. You can insert the command "DO Dot" at various problem points
in your program. When this command is encountered, you will be able to
enter interactive commands without destroying the current environment
of the program at runtime. Once the program is fully debugged, you can
remove the "DO Dot" command lines.
* Dot.PRG
DO WHILE .T.
ACCEPT 'DOT ' TO command
IF LEN( TRIM(command) ) = 0
EXIT
ENDIF
&command
ENDDO
RETURN
>>> Demonstration Disk (RunTime+)
In the Developer's Release of dBASE III, the dBRUN programs from
the Demonstration Disk are not compatible with the full system. Code
crunched with DBC.COM from the Demonstration Disk can only be run with
dBRUN from the Demonstration Disk. Code crunched with DBC.COM from the
Developer's Disk can only be run with the full dBASE III system or the
dBRUN disk, purchased separately. The error message:
No database is in USE. Enter filename:
is a common indicator that the incorrect dBRUN or dBC is being used.
>>> DISPLAY and LIST
The DISPLAY and LIST commands are documented inthe manual as not
having a FIELDS clause as part of the syntax, while the ASSIST and HELP
menu options assume the FIELDS clause is required. dBASE III will
accept either syntax for these two commands.
>>> Duplicate Keywords in Config.DB
If two or more COMMAND = <value> lines are contained in the
Config.DB file, only the last COMMAND will execute. This is true of
any duplicate <keyword> = <value> entry in the Config.DB file, with the
exception of DELIMITERS, which can legitimately have two entries. This
is true for versions 1.0 and 1.1 of dBASE III.
>>> FILE() function
The FILE() function only searches the current directory. SET PATH
TO does not affect this function. If other directories are to be
searched, they must be supplied to the function. For example,
* ---This will not find Data.dbf, if Data.dbf is in the
* ---subdirectory ACCTS.
SET PATH TO \DBASE\ACCTS
IF FILE( "DATA.DBF" )
DO Process
ENDIF
Workaround:
* ---This method will work.
mpath = "\DBASE\ACCTS\"
SET PATH TO &mpath
IF FILE( mpath + "DATA.DBF" )
DO Process
ENDIF
>>> CTOD() Function
The dBASE III Reference Manual does not clearly state that the
CTOD() function will convert invalid dates to valid dates. The day is
adjusted first.
? CTOD("02/29/85")
03/01/85 <------------ Extra day is added to month.
? CTOD("02/29/84")
02/29/84 <------------ Leap years are correct.
If the month is invalid, it is divided by twelve and the year is
adjusted. For example:
? CTOD("13/01/84")
01/01/85 <------------ Extra month is added to year.
? CTOD("12/32/84")
01/01/85 <------------ Extra day is added to month,
extra month is added to year.
? CTOD("99/99/62")
Menu 3
>>> FIND / SEEK
FIND and SEEK are both used to move the record pointer of an
indexed database to the first instance of the index key that matches
the search argument. FIND searches on a literal character string while
SEEK searches on an expression the value of which may be character,
date, or numeric. The proper choice of command is related to the
context and data type of the index key. Generally, FIND will only be
used to search for a literal character string and SEEK for all other
searches. The following are some typical cases:
(1) You have an index key that is character and are working from
the dot prompt:
. FIND Lee
or
. SEEK "Lee"
(2) You have an index key that is numeric or date and are working
from the dot prompt:
. SEEK 1250
. SEEK CTOD('12/12/85')
(3) You are working within a command file and are initializing a
memory variable as a search key:
STORE SPACE(10) TO skey
@ 10,10 SAY 'Enter value to search for' GET skey
READ
SEEK skey
(4) You have a database field that is character, Code, and the
contents are numeric digits and right-justified:
ACCEPT 'Enter code to search for' to skey
SEEK SPACE(LEN(Code) - LEN(skey)) + skey
(5) You are working with several databases and want to search for
a key value in the current work area using a field variable from a
non-active area with an alias name:
SELECT 1
USE File1 INDEX File1
SELECT 2
USE File2 INDEX File2
SELECT File1
SEEK File2->Field1
>>> Function Keys
F1 toggles the cursor control menu on and off in the following
full screen edit modes.
APPEND EDIT MODIFY LABEL MODIFY STRUCTURE
BROWSE CHANGE MODITY REPORT
>>> Get Diskspace
In the Developer's Release use the DISKSPACE() function to get the
amount of space left on the currently logged drive. The DISKSPACE()
will return the number of free bytes on the default drive as a numeric
value. dBASE III versions 1.0 and 1.1 do not have a function to return
the amount of space left on the default drive. So, to get the amount
of diskspace in these versions, use the PC/MS-DOS utility CHKDSK and
import the results into dBASE III. The basic algorithm is as follows:
1. Create or have available a general purpose database file called
Util.DBF. Util.DBF has one field called Util_line which is character
type and has a length of 80. This database file will be useful for any
of these kinds of survey operations into PC/MS-DOS.
2. RUN CHKDSK including the designator of the drive for which you
want the space statistic for, and pipe the result into a text file
entitled Util.TXT. Piping is a PC/MS-DOS capability that allows the
results of a program to be sent into a text file. It is very useful
for passing parameters between programs when there is no formalized
interface. The syntax is:
<DOS commmand> > <result text file>
^_____ DOS piping symbol
For more information on this capability, consult your PC/MS-DOS
reference manual.
3. APPEND the text file, Util.TXT, into the database file,
Util.DBF.
4. Assign to a memory variable the number of free bytes on the
specified drive from Util.DBF. This operation requires that you GOTO
the record that contains the free disk space information and then
extract the number of bytes from the field using the SUBSTR() function.
The following is a LIST of Util.DBF with the results of a CHKDSK
report. When APPENDed into a database file, the first and last records
are always blank. Records 2 through 6 contain statistics about the
currently logged disk drive. Note that this is the currently logged
DOS drive and not the DEFAULT drive SET in dBASE III. Records 8 and 9
contain statistics about the memory configuration of your computer.
The number of bytes for each attribute of the drive and memory occupy
positions 1 through 9 in the database field, Util_line.
Record#
1
2 9965568 bytes total disk space
3 155648 bytes in 4 hidden files
4 90112 bytes in 22 directories
5 6000640 bytes in 397 user files
6 3719168 bytes available on disk
7
8 524288 bytes total memory
9 122480 bytes free
10
The code that will get the the number of free bytes on the
specified disk drive is as follows:
SET SAFETY OFF
RUN CHKDSK > Util.TXT
USE Util
ZAP
APPEND FROM Util SDF
GO 6
diskspace = STR( SUBSTR( Util_line, 1, 9 ), 9 )
USE
SET SAFETY ON
RETURN
>>> Get Current Directory
dBASE III has no facility to get the name of the current directory.
To get it you must RUN the PC/MS-DOS command CD and import the results
into dBASE III. The basic algorithm is as follows:
1. Create or have available a general-purpose database file called
Util.DBF. Util.DBF has one field called Util_line which is character
type and has a length of 80.
2. RUN the PC/MS-DOS command CD, piping the result into a text
file entitled Util.TXT.
3. APPEND the text file Util.TXT into the database file, Util.DBF.
4. Assign to a memory variable the name of the current DOS
directory from Util.DBF.
The code that will execute this algorithm is as follows:
SET SAFETY OFF
RUN CD > Util.TXT
USE Util
ZAP
APPEND FROM Util SDF
currdir = TRIM( Util_line )
SET SAFETY ON
RETURN
>>> Get Last Update Date and Time
To get the date of last update for the currently SELECTed database
file in the Developer's Release of dBASE III, use the LUPDATE()
function. LUPDATE() returns the date of last update as a value of date
type. dBASE III versions 1.0 and 1.1 currently do not have a function
that returns the date of last update for the SELECTed database file.
To get the date of last update in these versions of dBASE III, use the
PC/MS-DOS command DIR, and import the results into dBASE III. The basic
algorithm is as follows:
1. Create or have available a general purpose database file called
Util.DBF. Util.DBF has one field called Util_line which is character
type and has a length of 80.
2. RUN the PC/MS-DOS command DIR with the name of your database
file, piping the result into a text file entitled Util.TXT.
3. APPEND the text file Util.TXT into the database file Util.DBF.
4. Assign to a memory variable the date of last update from
Util.DBF for your database file.
The code that will get the last update of the currently SELECTed
database file is as follows:
SET SAFETY OFF
RUN DIR <Yourfile>.DBF > Util.TXT
USE Util
ZAP
APPEND FROM Util SDF
lupdate = SUBSTR( Util_line, 25, 8 )
luptime = SUBSTR( Util_line, 34, 6 )
USE
SET SAFETY ON
RETURN
>>> INPUT
The INPUT command does not initialize a memory variable of any
type if <RETURN> is pressed at its prompt. The dBASE III manual says
this will produce a syntax error (page 4-58). What really happens is
that a syntax error will result if the non-existent memvar is later
referenced.
>>> MACRO (&) Substitution in a Format (.FMT) File
Macro (&) substitution will not work in a format (.FMT) file. For
example:
Structure for database: Macro.DBF
Number of records:
Date of last update: 05/01/85
Field Field name Type Width Dec
1 FLD01 Character 10
2 FLD02 Character 10
3 FLD03 Character 10
** Total ** 30
* Program..: Macro.PRG
* Note.....: This program will not display any field from
* the database file.
CLEAR
PUBLIC month
month = " "
USE Macro
ACCEPT "Enter two digits 01, 02, or 03: " TO month
SET FORMAT TO Macro
READ
CLOSE FORMAT
CLEAR
RETURN
Macro.FMT contains one line:
@ 05,30 SAY Fld&month
If the SET FORMAT TO Macro, READ, and CLOSE FORMAT command lines
are removed and DO Macro.FMT is inserted in their place, the program
will execute as expected and the field will be displayed.
>>> MEMO fields
(1) MEMO fields are used to contain up to 5,000 characters of text
information that is to be associated with a database record. Information
may be read into a MEMO field using Ctrl-K-R and written to text files
using Ctrl-K-W. Information from MEMO fields can be displayed or
printed by using LIST, DISPLAY, ?. The field must be specified with
these commands. However, these commands cause the MEMO field to wrap
at 50 columns. The REPORT FORM may be used to output MEMO fields with
line widths of more or less than 50 characters.
(2) PACKing a database file with memo fields will not decrease the
amount of disk space used by the .DBT file. The command file below
demonstrates how to remove the deleted records and free the unused disk
space.
SET DELETED ON
USE Filea
COPY TO Temp
CLOSE DATABASE
ERASE Filea.dbf
ERASE Filea.dbt
RENAME Temp.dbf TO Filea.dbf
RENAME Temp.dbt TO Filea.dbt
SET DELETED OFF
(3) When APPENDing FROM a database file with a memo field, the
target .DBT file will be at least as large as the source .DBT regardless
of how many records are APPENDed. This is because the target .DBT file
contains all the information that was contained in the source .DBT file.
Be sure to note this any time you are moving records from one database
file that contains memo fields to another. There is a danger of
unexpectedly filling a disk when doing this operation.
>>> MODIFY STRUCTURE
In MODIFY STRUCTURE, Ctrl-Home will bring up a menu on line 0 with
the four choices listed below.
Bottom Top Field # Menu
They are selected with cursor control keys and <RETURN>. Bottom
moves the cursor to the last field, Top to the first. Field # allows
selection of a field number, then moves the cursor to it. Menu toggles
the cursor control menu off and on. This feature is not documented
under MODIFY STRUCTURE.
>>> MODIFY STRUCTURE
The "Warning" in the documentation on page 4-73 of dBASE III
version 1.00 and WARNING of page 4-80 of dBASE III version 1.10 should
read as follows:
WARNING: Although you may change field names and field lengths,
if you change both at once, the data of the fields that have been
modified will not be appended into the new structure.
Note that in the ASSIST mode, the following screen message is not
entirely true, "Information in the database file is preserved where
field names remain the same." As noted above, if only field names are
changed or only the length, the data is appended into the new structure.
The correct procedure when both field name(s) and field length(s) need
to be changed, is to modify the field name(s) first, and then re-enter
MODIFY STRUCTURE and modify the field length(s). Also, note that
deleting a field (with Ctrl-U) has the same effect as modifying the
field length. Therefore, make deletions at the same time you make
field length changes.
>>> LABEL FORM command
If TRIM() functions are the only expressions on a line in a LABEL
FORM, dBASE III will return "*** Execution error on SUBSTR(): start
point out of range" when the LABEL FORM encounters a record in which
all TRIMmed fields are blank.
>>>LOCATE and CONTINUE
The LOCATE and CONTINUE commands cannot be used between two or
more work areas at the same time. If a LOCATE is issued in one work
area then issued again in another work area, a CONTINUE in the original
work area will result in a SKIP to the next record, not a CONTINUE.
The following program segment illustrates how to LOCATE and CONTINUE
between two data files.
SELECT 2
USE Test
SELECT 1
USE Test1
LOCATE FOR One > 1
DO WHILE .NOT. EOF()
? "FIELD Test1->One: " , One
SELECT 2
LOCATE FOR one > 1
DO WHILE .NOT. EOF()
? "FIELD Test->One: ", One
SKIP
LOCATE NEXT 1000 FOR One > 1
ENDDO ^-------------- should be larger
SELECT 1 than last record
SKIP number in file.
LOCATE NEXT 1000 FOR One > 1
ENDDO
The dBASE III Reference Manual entry for MODIFY LABEL, states that
"when you place several field names on one line of the LABEL contents
screen, dBASE III eliminates the extra blank spaces and prints the
label with only one space between fields." This should read, "when you
place several field names, separated by commas, on one line, etc."
Concatenations of fields appear as they always do.
Menu 4
>>> Numeric fields with decimal places
Although not documented, dBASE III expects the user to allow for a
leading digit and a decimal point on numeric fields containing decimal
places. For example, a numeric field of two decimal places should not
be defined any smaller than four digits in length -- one position for
the leading digit, one position for the decimal point and two positions
for the two decimal places. If the structure for a numeric field does
not allow for a leading digit (such as a width of three and two decimal
places), numeric input to the numeric field will always be stored as
zero. Also, if other numeric fields follow this field, they might
automatically be zeroed out when numeric data is entered to the first
field.
>>> Numeric input of large numbers
If a variable is initialized to zero, dBASE III does not allow
input larger than 10 digits when using the @...GET command, even if the
PICTURE clause is used. For example:
x = 0
@ 5,5 SAY "Enter digits" GET x PICTURE "99999999999"
* (There are eleven 9's) ----------^
READ
The display is:
Enter digits 0
If an eleven digit value is entered, the display is:
Enter digits ********** (10 asterisks)
This can be avoided by initializing 'x' to a value greater than ten
digits (such as, 1000000000). This problem does not occur if a field
is used rather than a memory variable.
>>> PARAMETERS, passing Fields
In the documentation concerning PARAMETERS when used in conjunction
with the DO <filename> [WITH <parameter list>] command, page 4-76 of
the version 1.0 manual states, "A passed parameter may be any legitimate
expression." Also, in the Glossary (page 7-3) the definition for
Expression is, "Expression may consist of a field, a memory variable,
a function, a constant, or any combination thereof." However, when a
DO is invoked with a field in the parameter list, dBASE III will give
the message, "Variable not found." In order to use a field name in the
parameter list, you must use the Alias -> Fieldname form. For example:
USE Filea
DO <Filename> WITH Filea -> Field1
will work, but the following will not.
USE Filea
DO <Filename> WITH Field1
Menu 5
>>> PRIVATE
In dBASE III, all variables are PRIVATE to the routine in which
they are initialized unless otherwise declared. Variables created at
the dot prompt will automatically be PUBLIC no matter how they are
declared. Declaring a variable PRIVATE in a command file hides any
outer-level definition of a variable with the same name from the current
routine. It also hides any deeper-level routines from viewing any
outer-level definition of a variable with the same name. In the example
below, programs B.PRG and C.PRG do not have access to variable X in
program A.PRG. Program C.PRG, therefore, will display X with a value
of 15 and not 10. Program A.PRG, however, will diplay X with the old
value of 10 even after executing program B.PRG.
* A.PRG
x = 10
DO B ----------> * B.PRG
? x PRIVATE x
RETURN x = 15
DO C ----------> * C.PRG
RETURN ? x
RETURN
In programming, you will want to declare a variable PRIVATE in a
subroutine if you do not want this variable to interfere with an
outer-level variable having the same name. To illustrate the use of
PRIVATE, the command files MAIN.PRG and SUB.PRG are listed below, with
the displayed output. Notice that all the variables are released when
MAIN.PRG returns control to the dot prompt. Also notice that the
variables initialized in MAIN.PRG are PRIVATE in the memory display
even though they are never explicitly declared. Lastly, notice that
the value assigned to height in SUB.PRG is not returned to MAIN.PRG,
but the value assigned to area in SUB.PRG is returned. This is because
height is declared PRIVATE in SUB.PRG and area is not.
LISTINGS:
* MAIN.PRG
* --------
area = 0
height = 304
? "Before call to SUB:"
? "-------------------"
DISPLAY MEMORY
DO Sub ------------------> * SUB.PRG
? "After call to SUB:" * -------
? "------------------" PRIVATE height
DISPLAY MEMORY height = 30
RETURN area = 10 * 20 * height
* EOF: MAIN.PRG ? "Inside SUB:"
? "-----------"
DISPLAY MEMORY
RETURN
* EOF: SUB.PRG
OUTPUT:
Before call to SUB:
-------------------
AREA priv N 0 ( 0.00000000)
HEIGHT priv N 304 ( 304.00000000)
2 variables defined, 18 bytes used
254 variables available, 5982 bytes available
Inside SUB:
-----------
AREA priv N 6000 ( 6000.00000000)
HEIGHT priv (hidden) N 304 ( 304.00000000)
HEIGHT priv N 30 ( 30.00000000)
3 variables defined, 27 bytes used
253 variables available, 5973 bytes available
After call to SUB:
------------------
AREA priv N 6000 ( 6000.00000000)
HEIGHT priv N 304 ( 304.00000000)
2 variables defined, 18 bytes used
254 variables available, 5982 bytes available
lines will display:
0 variables defined, 0 bytes used
256 variables available, 6000 bytes available
>>> PROCEDURE -- Calling Command Files from Procedures within dBASE III
To call a command file from a procedure, you must follow a few
rules.
Rule 1: The command file cannot have the same name as any of the
procedres in the file even if the extension is included as part of the
filename. An attempt to do this will cause the inappropriate error
message, "Unrecognized phrase/keyword in command." For example:
* Proc_ne.PRG
PROCEDURE One
* ---The next command will not work because
* ---Two is a procedure in this file.
DO Two.PRG
RETURN
*
PROCEDURE Two
* ---The next command will work.
DO Three.PRG
RETURN
* EOF: Proc_One.PRG
This can be avoided by renaming either the command file or
procedure. To avoid this problem you might want to begin procedure
names with a prefix that command files will not have. For instance, in
the previous example the procedures could have been called P_One and
P_Two.
Rule 2: Once the command file is invoked from a procedure file,
it must not DO another procedure in the procedure file. Instead, it
should RETURN to the calling procedure. Otherwise, the called procedure
will usually execute, but an error message will be displayed for a
command line that does not exist.
Rule 3: Internal procedure calls (that is, a procedure that calls
either itself or another procedure in the same file) must be kept to
eighteen nested calls or less. The nineteenth call attempt will return
execution to the calling command file with no error message.
>>> PROW()
When issuing SET PRINT ON, PROW() will be set to 2, regardless of
its previous setting. An EJECT will reset PROW() to 2, not 0. Issuing
an EJECT with SET PRINT OFF will reset PROW() to 0. When SET PRINT is
ON, PROW() may never equal 0 or 1. Any attempt to test for PROW() = 0
or PROW() = 1 will work only when SET PRINT is OFF.
Menu 6
>>> PUBLIC
PUBLIC is used to declare memory variables as global and to prevent
their release when control is returned to the dot prompt. PUBLIC
variables must be declared prior to being initialized, and once
declared, these variables will be assigned a logical false value until
initialized. PUBLIC variables can be re-declared as PUBLIC without
losing the values already stored in them. In programming, declaring
all variables as PUBLIC in the main routine would make dBASE III behave
similar to dBASE II. However, there is one difference in dBASE III,
PUBLIC variables can only be released by the CLEAR MEMORY, CLEAR ALL,
and RELEASE <variable list> commands, but not the RELEASE ALL command.
>>> Ramdisks
There are several options for users who wish to use a ramdisk in
combination with dBASE III.
1. For faster operation of applications that utilize routines
stored in the DBASE.OVL file, you may wish to put the .OVL in a ramdisk.
(a) The minimum drive size will have to be in excess of 181,000
bytes. The DBASE.OVL file for version 1.1 is 180,736 bytes. The total
amount of RAM in your machine must be more than 440,000 bytes in order
to do this. Additionally, if you are using a CONFIG.DB, it must be
present on the drive where .OVL resides.
(b) Boot dBASE III from the ramdisk by calling for the DBASE.COM
from the drive on which it resides. For example: drive D: is the ramdisk
and the DBASE.COM is on the C: drive.
C> D:
D> C:DBASE
2. It may be a very useful area for procedure or command files to
be run from, increasing the speed of processing. Prior to entering
dBASE III, copy the appropriate files to the ramdisk. Once in dBASE
III, SET the DEFAULT TO the ramdisk drive and proceed.
3. It is also useful as a small work area to manipulate utility
and temporary files. The useage tips on getting the current directory
or diskspace are good examples of where a small ramdisk would be
extremely useful and time efficient.
>>> RELEASE, incorrect syntax
The syntax "RELEASE ALL LIKE <skeleton>,<skeleton>" is incorrect
but will not produce an error message. The correct syntax is either
RELEASE <memvar list> or RELEASE ALL LIKE <skeleton>. You may use
wildcard characters in the RELEASE ALL LIKE form of the command, but
dBASE III will ignore any <skeleton> after the first comma.
>>> RELEASE ALL, CLEAR MEMORY
RELEASE ALL and CLEAR MEMORY are not equivalent commands as the
dBASE III manual states. CLEAR MEMORY clears all memory variables,
regardless where they were initialized. RELEASE ALL, however, will
release all memory variables except those declared PUBLIC or
initialized in a nested command file.
>>> REPLACE
REPLACE ALL does not replace all records correctly if an index is
in use and the key field is replaced. Only the first record and those
that logically follow the new value will be replaced. This occurs
because the index is automatically updated (in-place key updating) when
it is edited. The record pointer moves to the record following the new
position, not to the record following the old position. This can be
illustrated in the example given below (the data file has five records
with the field CHARS-C-1, and is indexed on this field):
. LIST
Record# CHARS
1 a
2 b
3 c
4 i
5 j
. REPLACE ALL Chars WITH 'd'
3 records replaced
. LIST
2 b
3 c
1 d
4 d
5 d
The manual warns against block replacements to the key field. The
correct procedure would be to REPLACE with no indexes in use, open the
indexes with SET INDEX TO, and then REINDEX.
>>> REPORT FORM--Dates
If you have a date-oriented report and you need to have it grouped
by week, the following discussion will assist you. The grouping of
dates into weeks has two requirements. First, the database file you
are reporting from must be INDEXed on the date field that is being
grouped on. Second, as the group expression in your REPORT FORM, you
must have an expression that returns as its value the first day of the
week for each date field. The expression is as follows:
Yourdate - ( DOW( Yourdate ) - 1 )
When given any date value, this expression returns the date of the
previous Sunday. It does this by subtracting from your date field the
number of days that have passed since the last Sunday, the first day of
the week in the dBASE III calendar. This value is obtained by
subtracting 1 from the result of the DOW() function. If you wish to
have the week you are grouping on start on a later day such as Monday,
subtract more from the result of the DOW() function. For example,
Monday would be DOW() - 2, Tuesday DOW() - 3, and so on.
>>> REPORT FORM HEADING
There appears to be some confusion about the use of the HEADING
option to the REPORT FORM command. The argument of the HEADING
statement is a character expression and, therefore, can contain any
combination of memory variables, field variables including aliases, and
functions that evaluate to a value of character type. This means that
macro substitution is not necessary to in order to use variable data
for the REPORT FORM in question. As a typical example:
* ---Set up header string.
title = "Sample Report Number 1"
*---Run the report.
REPORT FORM YourRpt HEADING title
If the HEADING argument is a field variable from the database file
being REPORTed on, the value of the HEADING will be the field value
from the record being pointed to when the REPORT FORM is invoked. For
example, if the current record number is 5 and a REPORT FORM is run
with no scope, the HEADING value is set from record 5 and then the
record pointer is reset to the top of file. The ability to use a
database field as the HEADING argument presents some interesting
possibilites. Suppose you have a master client and transaction file.
You wish to have a transaction listing for a particular client with
that client's name at the top of the REPORT FORM. The transactions
database file is INDEXed in client number order.
* ---Open database files.
SELECT 1
USE Client
SELECT 2
USE Transaction INDEX Transaction
SELECT Client
* ---Get the client to report on.
LOCATE FOR Name = "Smith"
* ---Report client's transactions.
SELECT Transaction
REPORT FORM Transaction HEADING Client->Name;
WHILE Number = Client->Number
>>> REPORT FORM, MODIFY REPORT
(1) The report generator will right-justify field headings for
numeric fields when the report is run.
(2) If the PLAIN clause is specified with REPORT FORM TO PRINT, no
page ejects occur. The report prints through to the end without page
breaks.
(3) 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.
(4) Although not documented in the manual or in the cursor control
menu, Ctrl-N inserts a column in a report being created or modified.
However, its counterpart (Ctrl-U which deletes a column) is documented
and included in the help menu.
>>> REPORT FORM <filename> PLAIN
The PLAIN option of the REPORT FORM command will cancel out the
HEADING option when these two are used in the same command line.
Therefore, do not use these two options in the same command. For
example, the following command line will not print the HEADING "Week
of May 6, 1985":
REPORT FORM Wksales PLAIN HEADING "Week of May 6, 1985" TO PRINT
>>> RANGE command
The dBASE III Reference Manual states that RANGE may be used to
specify lower and upper bounds for date variables, but does not clarify
that the arguments of the RANGE clause involving literal dates must be
in the form, CTOD("mm/dd/yy"). For example:
@ 10,10 GET Mdate RANGE CTOD("01/01/85"), CTOD("01/01/86")
>>> REPORT FORM
The semicolon is not documented as functioning as a Carriage
Return/Line-Feed in certain parts of REPORT FORMs.
Menu 7
>>> Reserved Device Names in MS-DOS
The MS-DOS manual specifies that certain names have a special
meaning to MS-DOS. Do not use these reserved device names as dBASE III
filenames: CON, AUX, COM1, COM2, LPT1, PRN, LPT2, LPT3, or NUL. This
applies to database files, index files, command files, format files, or
form files. Various error messages will result when files with any of
these names are accessed.
>>> Reserved words
Page 1-138 of the tutorial in the first edition of the manual uses
a sample routine which creates a memory variable with the name
'continue.' Since this is a reserved word, dBASE III will give the
message, "No database in USE, enter filename." dBASE III is assuming
you intend to CONTINUE on a LOCATE command. This will only happen if
you use the <variable> = <value> frm of assignment; dBASE III will
execute correctly when you use the STORE <value> TO <variable> form.
Other words that will not work with the first syntax are: AVERAGE,
COUNT, and SUM.
>>> ROW(), COL()
After a READ, the ROW() function always returns 24; however, the
COL() function does not change. For example:
SET TALK OFF
var = SPACE(2)
@ 5,40 GET var
? ROW(), COL() <--- This returns 6 and 3.
READ
? ROW(), COL() <--- This returns 24 and 3.
>>> RUN (or !)
The RUN command requires that COMMAND.COM be in the boot drive or
the directory indicated by SET COMSPEC. Otherwise, the incorrect error
message "Insufficient memory" is displayed.
>>> RUN COMMAND
You can get the equivalent to Framework's DOS Access in dBASE III
by issuing RUN COMMAND. This will leave you at the DOS operating system
level and will allow you to enter any DOS commands. To get back to the
dBASE III dot prompt, type EXIT.
>>> SET ALTERNATE TO
dBASE III will not send a linefeed (that is, CHR(10)) to an
alternate file (WordPerfect looks for this linefeed character in its
mail merge program). The following command file:
SET ALTERNATE TO x
SET ALTERNATE ON
?? "first LF"
?? CHR(10)
?? "second LF"
SET ALTERNATE OFF
CLOSE ALTERNATE
will generate the following test file:
first LFsecond LF
As you can see, there is no linefeed in the file.
>>> SET COLOR
(1) To get enhanced video to be black on black, use the command SET
COLOR TO x/y,0+/0. Black on black is frequently used to allow user
input without displaying the characters on the screen, as with entry of
a password.
(2) The command: SET COLOR TO ,<cr> will produce black on black,
even if there is no space after the comma.
(3) The asterisk (*) used with the SET COLOR command allows you to
have blinking characters on the screen. The asterisk must be used in
conjunction with a color parameter. For example:
SET COLOR TO 6*/1,7/4,6
or:
SET COLOR TO GR*/B,W/R,GR
>>> SET COLOR TO on the Compaq computer
SET COLOR TO U on the Compaq computer will not generate underlining.
Instead, SET COLOR TO U and SET COLOR TO I give quarter intensity.
Using U+ or I+ will generate half intensity. You will not get the
monochrome attributes, because the Compaq monitor is operating as if
it where color.
>>> SET CONSOLE ON/OFF
The SET CONSOLE ON/OFF command behaves differently in dBASE III
than it does in dBASE II. Specifically, it has no effect when issued
at the dot prompt, and if SET CONSOLE OFF is issued in a command file
that neglects to SET CONSOLE ON, dBASE III will automatically set the
console back on upon the termination of execution of that file. This
includes normal termination as well as termination by means of pressing
the escape key.
>>> SET DEBUG ON
SET DEBUG ON overrides SET CONSOLE OFF and output will be echoed
to the screen.
>>> SET DELETED
SET DELETED in dBASE III applies to all commands, unlike dBASE II,
where certain commands ignore the status of SET DELETED. In dBASE III
you are permitted to COPY, APPEND and REPORT deleted records if DELETED
is set OFF.
>>> SET DOHISTORY ON/OFF (Developer's Release)
If your dBASE III Developer's Release Reference Manual does not
contain page 4-115A in the Commands section which explains the use of
SET DOHISTORY, the following documents the command. SET DOHISTORY
determines whether or not commands from command files are recorded in
HISTORY.
Syntax: SET DOHISTORY ON/OFF
Defaults: SET DOHISTORY is normally OFF
Usage: When SET DOHISTORY is ON, commands that were executed from
within command files are stored in HISTORY. You can then
edit these in full-screen edit mode and execute them. Note
that SET DOHISTORY has no effect on commands you issue from
the dot prompt.
Tips: In conjunction with SUSPEND, SET DOHISTORY is useful for
debugging. However, because SET DOHISTORY slows down command
file execution, use it only when debugging.
See Also: DISPLAY HISTORY, LIST HISTORY, RESUME, SET DEBUG, SET ECHO,
SET HISTORY, SET STEP, SUSPEND
>>> SET FILTER TO
(1) The SORT command will only sort those records that meet the
filter condition. The INDEX command will index all records in the file
whether or not they meet the filter condition. However, a FIND command
will return "No find" if the key falls outside the scope of FILTER.
(2) Some users are confused regarding the performance that may be
expected when using the SET FILTER TO command. The database file is
not smaller in size when a filter is set. Consequently, activities
that access the file are not proportionately faster. Commands that
operate on the FILTERed set of records must still scan the entire
database file.
>>> SET MENUS ON/OFF
The default for SET MENUS is OFF. However, ASSIST leaves MENUS
SET ON even if they were off prior to entering ASSIST.
>>> SET PROCEDURE TO, PARAMETERS, PROCEDURE
The following program and procedure files illustrate the use of
parameter passing with procedures. FUTVALUE.PRG calculates the future
value of an investment and the future value of an annuity with the use
of the BUSINESS.PRG procedure file. Notice how the parameters can be
passed to BUSINESS.PRG. They can either be literal numbers, expressions
or variables. Also, notice that the PARAMETERS command is included
after each PROCEDURE that receives parameters.
LISTINGS:
* FUTVALUE.PRG
* ------------
SET TALK OFF
SET FIXED ON
SET PROCEDURE TO Business
*
* { Calculate future value of an investment
result = 0.00
DO FV WITH 6000.00, 8.5, 4, 5, result
? result
*
* { Calculate future value of regular deposits (Annuity)
result = 0.00
DO FVA WITH 150.00, 7.0, 12, 2, result
? result
*
CLOSE PROCEDURE
SET FIXED OFF
SET TALK ON
RETURN
* EOF: FUTVALUE.PRG
* BUSINESS.PRG { Library of business procedures
* ------------
*
PROCEDURE FV { Calculate future value of an investment
PARAMETERS amount, rate, periods, years, result
rate = rate / periods / 100
result = amount * (1 + rate) (periods * years)
result = ROUND( result, 2 )
RETURN
*
PROCEDURE FVA { Calculate future value of regular deposits
PARAMETERS amount, rate, periods, years, result
rate = rate / periods / 100
result = amount * ( (1 + rate) (periods *;
years) - 1 ) / rate
result = ROUND( result, 2 )
RETURN
*
* EOF: BUSINESS.PRG
OUTPUT:
9136.77
3852.15
Menu 8
>>> SET RELATION TO
The SET RELATION TO command takes precedence over the SET FILTER
TO and SET DELETED ON commands. That is, information from a related
database file will be displayed if addressed with an alias name, even
if that record has been filtered out with the SET FILTER TO command or
with SET DELETED ON. Please note that because of this, SETting FILTER
TO .NOT. DELETED() in another work area to exclude deleted records in
that work area will not work if that record is accessed with the alias
name. The following examples demonstrate that deleted and filtered
records may be accessed if they are addressed with SET RELATION TO.
Both database files consist of one 10-byte character field called One.
SELECT 1
USE Test1
SELECT 2
USE Test2
INDEX ON One to Test2
DELETE ALL <-- Delete all from Test2.
SET FILTER TO .NOT. DELETED() <-- Filter deleted records.
SELECT 1
SET RELATION TO One INTO Test2 <-- SET RELATION.
? One, B->One
AAAAAAAAAA AAAAAAAAAA
^--------------------- Field displays even though
it is deleted and filtered
from the Test2.DBF.
>>> SET RELATION TO <expression> INTO <alias>
(1) SET RELATION TO relates two database files by means of an
expression. It can be used in conjunction with REPORT, LABEL, LIST,
and many other commands to view information from more than one file.
In the examples below, the command files on the left and right sides
are identical in function. You will notice that it takes several more
lines of code to accomplish the same task if the SET RELATION TO
command is not used.
Example 1:
* ---Without SET RELATION. * ---Using SET RELATION.
* ---Linked by RECNO(). * ---Linked by RECNO().
SELECT 2 SELECT 2
USE Address USE Address
GO BOTTOM SELECT 1
STORE RECNO() TO last USE Names INDEX Alpha
SELECT 1 SET RELATION TO RECNO() INTO Address
USE Names INDEX Alpha DO WHILE .NOT. EOF()
DO WHILE .NOT. EOF() ? Name,Address->Phone
STORE RECNO() TO rec SKIP
SELECT Address ENDDO
IF rec <= last
GO rec
ELSE
GO last
SKIP
ENDIF
SELECT Names
? Name,Address->Phone
SKIP
ENDDO
Example2:
* ---Without SET RELATION * ---Using SET RELATION.
* ---Linked on key field. * ---Linked on key field.
SELECT 2 SELECT 2
USE Detail INDEX Custnbr USE Detail INDEX Alpha
SELECT 1 SELECT 1
USE Customer USE Customer
DO WHILE .NOT. EOF() SET RELATION TO Number INTO Detail
STORE Number TO mkey DO WHILE .NOT. EOF()
SELECT Detail ? Name,Detail->Phone
SEEK mkey SKIP
SELECT Customer ENDDO
? Name,Detail->Phone
SKIP
ENDDO
To use SET RELATION TO with reports and labels, set the relation
when the report or label is executed. When creating or modifying a
report or label, only the structure of the active database file in the
selected work area will be displayed at the top of the screen, so a
listing of the unselected database file will be necessary. To specify
fields from the unselected file, use the <alias>-><fieldname> form. In
order to print the report or label properly, both files will have to be
in use and the relation will have to be set before the REPORT r LABEL
command is issued.
>>> SET UNIQUE ON/OFF
The SET UNIQUE command determines whether duplicate key values will
be stored in index files. The use of SET UNIQUE affects:
1. How the INDEX ON command constructs the named index file.
2. How the REINDEX and PACK commands rebuild all open index files
in the currently selected work area.
3. How all open index files are maintained when the active database
is updated (such as in APPEND, BROWSE, CHANGE, EDIT, or REPLACE).
There is a tendency to believe that SET UNIQUE only needs to be
used when creating an index file. SET UNIQUE does not work this way.
The "uniqueness" of an index file is in no way attached to the file.
When additions, deletions, or changes to key information are made to
the database file, the index file must be open and SET UNIQUE must be
ON or OFF (default). It is not possible to maintain index files of
both unique and non-unique types for the same database file, unless one
of them is recreated with SET UNIQUE ON or OFF every time a record is
updated. Another item to consider when using "unique" and "non-unique"
index files is when they are used in different SELECTed work areas.
Updating indexed database files in different work areas will require
that UNIQUE be SET to the appropriate value for each SELECTed area.
>>> TRIM() with LIST or DISPLAY
Due to the introduction of headings for LIST and DISPLAY, the
TRIM() function may not work as you expect when used with these
commands. Specifically, if you LIST or DISPLAY a list of TRIMmed
fields, they will not be TRIMmed. Use an expression that includes the
TRIM function instead. For example:
LIST TRIM( Firstname ), Lastname
will not work, but the following will:
LIST TRIM( Firstname ) + ' ' + Lastname
>>> VAL() function
(1) In version 1.1, SET DECIMALS affects the VAL() function. Page
4-110 of the dBASE III User Manual states that SET DECIMALS applies
only to division, SQRT(), LOG(), and EXP(). Page 5-39 says that the
VAL() function does not display the decimal portion of a number.
However, how the output of the VAL() is displayed will correspond to
the number of decimal positions defined with the SET DECIMALS command.
For example:
SET DECIMALS TO
x = "1.1111"
? VAL( x )
1
SET DECIMALS TO 2
? VAL( x )
1.11
SET DECIMALS TO 10
? VAL( x )
1.1111000000
(2) Using any non-numeric argument with the VAL() function will
return 0.00. For example:
? VAL("Truth")
0.00
However, if an asterisk is used as the argument of the VAL() function,
it will return "****".
? VAL("*")
****
In dBASE III, the asterisk is used in this way to signal that an
operation resulted in a numeric overflow. If the VAL() function did
not return asterisks, some operations might obscure the fact that a
numeric overflow occurred. For example:
divisor = 0
dividend = 1
x = dividend/divisor
? x
**************
y = STR(x,1)
? y
*
z = VAL(y)
? z
****
If the VAL() function above returned 0, the quotient might have been
misinterpreted as being 0.
(3) In converting from a character expression to a numeric value,
the VAL() function evaluates the text from left to right until a
non-numeric character is encountered. Leading blanks are ignored. If
the function argument contains a mixture of number and text characters,
only the leading numeric characters will be converted to a numeric
value. For example:
? VAL( "12ABC" )
12.00
Trailing blanks are treated as non-numeric characters and, when
encountered, the conversion process is terminated. For example:
? VAL( "12 12" )
12.00
>>> Warning against using a dBASE III file in dBASE II
Whenever dBASE II attempts to read a database file, it writes a
hexadecimal two (02H) to the first byte of the file. Therefore,
attempting to USE a dBASE III file in dBASE II will make the file
unusable by dBASE III. Any attempt to USE the corrupted file in dBASE
III will give the error message "Not a dBASE database."
Menu 9
INDEX OF dBASE III REFERENCE TOPICS
Menu
Choice Topic
------ --------------------
1 @...GET...RANGE
@...GET and READ
@...GET...PICTURE
@...SAY...PICTURE
@...SAY using relative addressing
APPEND FROM <filename> [SDF/DELIMITED [WITH <delimiter>]]
2 Closing Database Files
COPY TO <filename> [SDF/DELIMITED [WITH <delimiter>]]
COPY FILE <source filename> TO <target filename>
COPY STRUCTURE EXTENDED / CREATE FROM
CREATE / MODIFY REPORT
Date conversion from dBASE II
Dates that are blank
Debugging tip
Demonstration Disk (RunTime+)
DISPLAY and LIST
Duplicate Keywords in CONFIG.DB
FILE() function
3 FIND / SEEK
Function Keys
Get Diskspace
Get Current Directory
Get Last Update Date and Time
INPUT
Macro (&) Substitution in a Format (.FMT) File
MEMO fields
MODIFY STRUCTURE
4 Numeric fields with decimal places
Numeric input of large numbers
PARAMETERS, passing Fields
5 PRIVATE
PROCEDURE
PROW()
6 PUBLIC
Ramdisks
RELEASE, incorrect syntax
RELEASE ALL / CLEAR MEMORY
REPLACE
REPORT FORM--Dates
REPORT FORM HEADING
REPORT FORM / MODIFY REPORT
REPORT FORM <filename> PLAIN
7 Reserved Device Names in MS-DOS
Reserved words
ROW() / COL()
RUN (or !)
RUN COMMAND
SET ALTERNATE TO
SET COLOR
SET COLOR TO on the Compaq computer
SET CONSOLE ON/OFF
SET DEBUG ON
SET DELETED
SET DOHISTORY (Developer's Release)
SET FILTER TO
SET MENUS ON/OFF
SET PROCEDURE TO / PARAMETERS, PROCEDURE
8 SET RELATION TO <expression> INTO <alias>
SET RELATION TO
SET UNIQUE ON/OFF
TRIM with LIST or DISPLAY
VAL() function
Warning against using a dBASE III file in dBASE II
9 This Index.
10 CONFIG.SYS
dCONVERT
File Control Blocks
Hard Disk Usage
Installing version 1.0
Prolok (version 1.0)
Menu 10
>>> CONFIG.SYS
(1) The DOS configuration file, Config.sys, which contains
FILES=20, must be in the root directory of the disk that DOS is either
cold or warm booted from. The consequence of its absence when operating
dBASE III is the unexpected error message "Too many files are open".
To correct this problem:
(a) Go to the root directory of the disk that DOS is booted from;
(b) Create a Config.sys by entering the following at the system
prompt:
A>copy con: config.sys <RETURN>
BUFFERS=15 <RETURN>
FILES=20 <RETURN>
Ctrl-Z <RETURN>
(c) Reboot DOS by pressing Ctrl-Alt-Del.
(2) Adding buffers and files with Config.sys is not free of memory
overhead. Each buffer uses 528 bytes and each file uses approximately
39 bytes. In addition, hard disks such as Davong and Corvus use large
amounts of memory. With BUFFERS and FILES set high, and a hard disk,
some 256K systems may not have enough room to run dBASE III. Reducing
these parameters to a lower amount (such as FILES=15 and BUFFERS=2) may
be the only way to run dBASE III on these systems.
>>> dCONVERT
(1) dCONVERT, version 1.0 has an option for converting dBASE III
files to dBASE II format. When this is chosen the first byte of the
file is changed from 03 to 02 and other changes are made to the header,
but a dBASE II format header is not created. The result is a file
unusable by dBASE II or dBASE III. To work around this problem, COPY
the dBASE III file to a text file using the SDF option. CREATE a file
in dBASE II with the same structure and APPEND the text file using the
SDF option.
(2) dCONVERT will not convert command files that use four-letter
abbreviations of dBASE II commands, such as DISP and ERAS.
(3) Some 1-2-3 users have found that dCONVERT will not convert the
dBASE II database files that 1-2-3's Translate utility generates.
Apparently Translate creates a database file that is not an exact
dBASE II database file. To work around this problem, create an ASCII
text file from your 1-2-3 worksheet by using the following procedure:
In Lotus 1-2-3:
(1) Setup a worksheet to print without headers and footers with
/ P rint F ile O ther U nformatted;
(2) Make the top, bottom, and left margins zero;
(3) Write the text file with / P rint F ile;
In dBASE III:
(1) CREATE a database that reflects the structure of the 1-2-3
worksheet;
(2) Read the text file into dBASE III with APPEND FROM <worksheet
name>.prn SDF.
>>> FILE CONTROL BLOCKS
dBASE III was designed to use the XENIX type "ASCII I/O handles"
when setting up FCB's (File Control Blocks) for its I/O. Whenever
dBASE III opens a file, DOS provides a control block. However, DOS
only has space for 20 such blocks (FILES = 20). Since DOS uses five
of these files, fifteen are left for dBASE III.
>>> HARD DISK USAGE
Customers using dBASE III with a hard disk system who wish to use
an external editor for MODIFY COMMAND or memo field when editing will
find that DOS checks the A: drive for COMMAND.COM whenever it loads the
external editor if A: is the boot drive. This can be avoided by setting
up the DOS environment to look for COMMAND.COM on the default drive
(hard disk) and subdirectory. The command to do this is:
SET COMSPEC=DRIVE\PATH\COMMAND.COM
This can be entered at the system prompt or placed in an AUTOEXEC.BAT
file. For example, if dBASE III were on drive C: in a subdirectory
called DBASE, the command would be:
SET COMSPEC=C:\DBASE\COMMAND.COM
You must of course have COMMAND.COM present in this subdirectory. If
the SET command is included in an AUTOEXEC.BAT file, "SET COMSPEC="
without any parameters must be included before the new command in order
to clear the default setting. The status of this command can be checked
by entering "SET" at the system prompt.
>>> INSTALLING dBASE III (version 1.0)
The errata sheet (dated June 18, 1984) that was shipped with the
first several thousand copies of dBASE III explains a method for making
the original system disk bootable using the SYS command. Unfortunately,
this will not work. Since the directory space for the system was not
reserved, the message, "No room for system on destination disk,"
results when SYS is run. In order to make bootable copies of dBASE III
the following procedur must be followed:
1. Format two disks and place the operating system on them with
the FORMAT d:/S command.
2. Copy DBASE.EXE and CONFIG.SYS onto one of the newly formatted
disks.
3. Copy DBASE.OVL, CONFIG.DB, HELP.DBS, and ASSIST.HLP to the
other new disk.
4. To boot dBASE III, place the copy of DBASE.EXE (disk from step
2. above) in drive A:, the original master system disk in drive B:,
start the computer, and enter:
DBASE <RETURN>
The message "Insert dBASE III overlay file diskette, or type Ctrl-C to
abort" will appear.
5. Remove the copy from drive A: and the master disk from drive B:.
Place the disk with the copy of the overlay file (from step 3.) in
drive A: and strike any key.
6. Place the master system disk in a safe place. It will not be
needed until dBASE III is started again. Drive B: is free for whatever
programs or data files you wish to work with.
>>> PROLOK (version 1.0)
(1) Each system disk that contains dBASE III is copy protected with
the Prolok copy protection scheme. Every time dBASE III is loaded,
Prolok which is internal to dBASE looks for the disk that has the
Prolok identification on it before passing control to the dBASE loading
routine. If the presence of the identifying disk is not sensed, the
message "Unauthorized Duplicate" is displayed and the loading of dBASE
is terminated. What must not be overlooked is that each copy of dBASE
III is uniquely identified with the system disk that it came from, much
as child to a parent. This is of particular importance to hard disk
users who copy dBASE III to, and boot from the hard disk. Users booting
from the hard disk will often attempt to use as the identifying disk a
system disk that the dBASE on the hard disk cannot identify as its
parent resulting in "Unauthorized Duplicate".
(2) The Prolok procedure is designed to physically damage the disk.
Therefore, running CHKDSK on it will report bad sectors -- 10240 bytes
in bad sectors, to be exact.