Contents of the QAD.DOC file
Quick And Dirty (QAD), an ASCII to Delimited File Converter.
VERSION 1.2. The program should now work well with any type of
screen: MDPA, HERC, CGA, EGA and VGA. The first version did not
display correctly on monochrome screens and the second version that
I put out to BBS's apparently still had the old version of QAD.EXE
even though the QAD.BAS file had all the fixes in it.
Written and Copyrighted by Kenneth B. Gash
6534 Eddinghill Drive
Rancho Palos Verdes, CA 90274
I was submitting this utility program as SHAREWARE, but since I don't like
receiving programs that don't work well any better than you do, I am now
removing any requests for money. If you find it as useful as I think you will
(presuming you have an application for it), I would like to know about it.
Please leave me a message on the BBS where you found this program to tell
me it works, or it stinks or what can be done to improve it. Thanks.
This program takes ASCII records conforming to certain simple
rules and allows you to "delimit" those records into whatever
fields you like. It can be used to convert data obtainable from
mainframe downloads, from data bases and spreadsheets which do
not export files in anything useful except ASCII and for files
ported from other systems as ASCII records.
It is entitled Quick And Dirty (QAD) because it was designed to
be a working utility with no bells and whistles.
Data bases are wonderful tools for manipulating large amounts of
data, but the data has to be entered before it can be
manipulated. Usually, the data is entered from the keyboard,
which can be a very tedious process.
On the other hand, data is often available as an ASCII list or
table which can be accessed with a word processor and can be sent
to a printer for hard copy. Unfortunately, it is usually not in
a form which is "importable" by standard data base programs. I
work at a university and I often access the central mainframe
computer for student and course schedule data. The people at the
computer center produced files containing many records of
ASCII data which I would then have to type into my PC for further
analyses and manipulation. This program is the result of my
frustration with this method of getting data into a data base.
Any collection of ASCII data that conforms to some simple rules
can be converted by this program to be imported into dBASE III,
REFLEX, or any other program which can recognize "delimited"
ASCII data files. A delimited data file is one in which each of
the fields in a record is separated from the next field by one or more
delimiters. This program uses two delimiters: the comma (,) and
the quotation mark (").
The program also is able to do some manipulation of the data as
it is delimiting it. One of the most common types of data bases
is a collection of names and addresses (which may also contain
additional data). In many cases, names are stored in as
LASTNAME,FIRSTNAME MI. This form is quite useful for sorting of
the lists but it is not very useful for generating mailing lists.
The program can convert names stored in this form to a delimited
LASTNAME, and a delimited FIRSTNAME MI. If you try to use this
feature on a field without a comma, the program will not allow it.
The program is also able to do "Proper Case Conversion" which means
that it will take an alphanumeric field that contains UPPER CASE
STRINGS and convert it to "Proper Case Strings" where only the
first character of each word is upper case. This again is useful
in converting name and address files obtained from various sources
since they are often stored as upper case only files.
The "Rules" for the file to be converted are:
1. Each record of the file must be contained in a single
line with no carriage returns or linefeeds.
2. Each record of the file must be made up of the same
number and type of fixed length fields.
3. The total number of characters in each record should be
no more than 240. This program is written in BASIC
which limits string length to 255 so 240 is set to
leave room for the delimiters.
4. Name fields which are to be delimited into first and
last name fields MUST have a comma separating the
LASTNAME and FIRSTNAME in the original field. The
program searches for the presence of a comma then
proceeds to separate the two parts of the name at that
5. When Proper Case Conversion is used, it may require some
touching up with a text editor (Henry Smith Iii or Po Box
or John, Jr. Jones or other minor errors will occur).
Using the Program
THe program was written in BASIC and compiled with Microsoft
Quick Basic 4.0. I have included the source file in case anyone
wants to modify the program, but the program runs fastest as
Enter the full pathname of the file to convert.
The program adds the extension .PRN if there was no extension.
If you don't like the default output file name, change it before
The program then places the first record in the input file on the
screen, gives its length in bytes and asks:
IS THIS A GOOD RECORD (Y OR N)?
A "good" record is one which contains few if any null or blank
fields so that it would be useful for marking appropriate fields
Once you find a good record and hit 'Y', the record is re-written
on the screen with the cursor activated to mark fields.
To mark a field, move the cursor using the left and right arrows
on the number pad so that the cursor is on the character just to
the right of the last character in the field to be marked.
Hit 'C' if you want the field to be separated by a COMMA
Hit 'Q' if you want both quotes and commas.
Hit 'N' if the field contains a name, WITH A COMMA
SEPARATING THE TWO PARTS OF THE NAME, and you want the first
and last names automatically delimited as separate fields.
This function uses only the QUOTE and COMMA delimiting.
**CAUTION -- THIS FUNCTION WILL CAUSE THE PROGRAM TO CRASH
IF IT TRIES TO DELIMIT A FIELD WHERE THERE IS NO COMMA.
While marking fields, you can do things like separating area
codes and/or dashes from telephone numbers, marking fields that are
not needed so that they may be discarded by your application
program and shortening the total record by a fixed amount. The
latter is done by simply not marking the entire record if the
last part of it contains unwanted information.
It is important to note that the last field you want MUST be fully
marked. Don't worry if it appears to have a trailing comma, that
will be removed in the conversion.
As you are marking the fields, you will notice that the Field
Number, Field Length and Total Length Marked are shown on the
screen. This feature is useful if you know the exact record
layout of the ASCII string you want to delimit and some of the
fields appear blank on the screen.
When all fields are marked, hit the ENTER key. You will then be
asked if you want to do Lower Case Conversion. If you answer
'N', you will be presented with a list the fields you have marked
to check. If everything looks OK, hit the enter key. If you
detect something wrong, hit the BACKSLASH (\) key to start over.
This key can be hit any time during the field marking procedure
to abort and start again. I'm afraid if you want to quit without
actually converting data, you must hit to get out
of the program. No frills, remember?
If you select Lower Case Conversion, each marked field will be
presented in order and you will be asked to enter 'Y' or 'N'.
Finally, when the list is done and you hit the ENTER key, the
conversion begins. If you have lots of lower case conversions,
the conversion is slowed down somewhat.
1. From the directory containing QAD.EXE, enter QAD.
2. Type in the full pathname of the ASCII file to be converted.
3. Accept the default output file or type in a new pathname.
4. Proceed to move the cursor with the arrow keys and mark the
5. When all fields are marked, hit the ENTER key, answer the
questions about lower case conversions and proceed to get
your data converted.
Since there is little or no error checking, your input file must
be "clean" or your output file may wind up with some strange
formats. Of course, the input file is not changed in any way, so
no real harm done.
The values I have chosen for the cursor highlight, foreground and
background and other colors used in marking the fields may not be
fully appropriate for your monitor. I have checked them on CGA,
EGA, VGA and Hercules type monitors, but variations do exist. If
that is the case, you should experiment with different values of
the values in LINE 80 and the value of PCOL in line 30.
Remember, MONO screens (including Hercules) have their screen
memory starting at &HB000 while color screens start at &HB800.
Of course, you should recompile (using Quick Basic, any version)
It is not a good idea to use files with the .PRN extension as
input files. If you do, and you do not rename the DEFAULT output
file, the program will crash since it will try to open the INPUT
file for OUTPUT!
If you find this program useful or if you don't think it works correctly, send
me a message to that effect. Thanks.