Category : Dbase (Clipper, FoxBase, etc) Languages Source Code
Archive   : TN9101.ZIP
Filename : Q_AND_A.TXT

This article is reprinted from the January 1991 edition of
TechNotes/dBASE IV. Due to the limitations of this media, certain
graphic elements such as screen shots, illustrations and some tables
have been omitted. Where possible, reference to such items has been
deleted. As a result, continuity may be compromised.

TechNotes is a monthly publication from the Ashton-Tate Software
Support Center. For subscription information, call 800-545-9364.

Q&A
That Was Then, This Is Now

I am having difficulty determining the data entry characteristics of a
social security number field which I am capturing to a memory
variable. The statement used is

@ 4,8 GET mvar PICTURE "999-999-9999"

Sometimes, there is no entry for that field. In that case, the
operator should be able to press Enter to go on to the next field.
The problem occurs when a user accidentally types in some datainto
that field. Pressing Ctrl-Y or using the Backspace key results in the
message: "Illegal value (press Space)". This effectively forces the
operator into padding the field with zeroes, a result which does not
work well with the logic of other data analyzing programs we have
developed.

This must be new to dBASE IV as we never experienced this problem in
dBASE III PLUS. How do we overcome it?

The data validation functionality in dBASE III PLUS was not a strong
point by today's standards. In dBASE IV, several clauses were built
into @.GET statements to assure more control over the accuracy of data
entry. In this evolutionary process, some simple processes in dBASE
III PLUS changed in dBASE IV. At any rate, the functionality is
changed, and here's how to program in the new method.

You can use the # as a template symbol. This will allow digits,
blanks and signs (+, - and . ). It is necessary to filter these out.
The UDF below should assist you in capably trapping for numerics while
not getting "stuck" in a field.

FUNCTION NBRS
PARAMETER INFIELD,TEMPLATE
* (Example: Nbrs(SSN,"###-##-####")
ctr = 1
DO WHILE ctr # len(template) .AND. ctr # 0
IF VAL(SUBSTR(Infield,ctr,1)) # 0 .OR.
SUBSTR(Infield,ctr,1) $ " 0"
ctr = IIF(SUBSTR(Template,ctr,1) $ "#9", ctr +
1, 0)
ELSE
ctr = IIF(.NOT. SUBSTR(Template,ctr,1) $ "#9",
ctr + 1, 0)
ENDIF
ENDDO
RETURN (ctr # 0)

Strung Out Using DTOS()

Would somebody help me? I can't seem to get the DTOS() function to
work for me!
If your argument is a literal string, you enclose it without quotes
inside curly brackets

? DTOS({01/01/91})

If the parameter is a date field or variable, simply putting the name
of the field as the function argument is suitable.

However, if the parameter is a character field, it is necessary to
first pass the field to a memory variable and employ macro
substituion. For example, a character field named Bdate which has the
value "01/01/90" would first need to be passed to a memory variable,
mdate, before using DTOS(). The expression ? DTOS({&mdate}) would be
correct.

This would only be necessary if it were imperative that the field
containing the date string be character type instead of a date type.
Converting the field to a date type would be easier in this case.

Spaced Out

I am creating a label program and want to trim the excess blanks off
of fields in the City, State and Zipcode fields. Is it true that I
have to create a calculated field to acocmplish this?

No, just connect everything together as one solid field. On the
design layout add the city field, immediately to the right add a
comma, next a physical space then the state field, two more physical
spaces and then the zip codefield.

A physical space is one where you press the spacebar, not the cursor
navigation (arrow) keys. The physical spaces act as connectors to the
field markers. When this method is used, the label compiler will
automatically perform a trim on each field within the line. So, to
answer your question more directly, no, you do not need a calculated
field.