bhoar@pro-novapple.UUCP (Brendan Hoar) (11/30/87)
Completed 8:30 PM on October 30th, 1987
AppleWorks Database Woes
(or how not to spend a good 8 hours)
Well, another long session stomping on bugs...but not killing them (so,
I'm not a great programmer, sue me. Anyway, if I were, I might have missed
some of these bugs! (probably shouldn't have said that!)).
Anyway, hopefully this will someday get to Tom Weishaar (Open-Apple, by
mail), Rupert Lissner (creator of AppleWorks, by modem at 702-831-1722),
and/or the Applied Engineering technical support and programming departments
(by mail).
Lets start from the beginning...
Part I: The sob story
Basically, I'm what Tom calls an intermediate computer user. Not an
experienced programmer, not a beginner. I use my GS almost everyday for a
variety of things, but mostly for telecommunications using local BBSs in my
home town of Alexandria, Virginia (right next to D.C.) and other nearby
cities. My father "employed" (implored?) me to create some nifty database
files in AppleWorks this summer to allow him to automate billing customers to
some degree...all info is entered at the end of the day from handwritten
tickets and then saved and used for billing at the end of the month (saves a
LOT of time!).
Well, a few days ago, my father called from his office and told me, in
summary, that he couldn't get the invoicing file to load, AND that he had
deleted the previous backup by mistake the very same morning AND written
another file over it (nope, UNDELETE won't work, and the beginning of the file
is written over!), and, finally, that the file was no longer on the desktop.
All I could think of about was watching him have to do all of the tickets by
hand, so I said to him, in summary, that if you bring all of the disks home
from the office, I'll try to see if I can repair it. And that's how it all
started...
Part II: How I fixed it
Day 1
First, I did all of the usual verification of the file in terms of
readability by ProDOS, etc...and it checked out fine. Then, I took a look at
all of the data in the file (knowing nothing at all about the format of an ADB
file and its header information) and compared it to the file used in the
previous month (same except different data entered for the tickets). I looked
at the beginning of the header and both had the same format (not same values,
but I assumed that if the data in the header was blown, I'd never be able to
fix it blindly with a sector editor...) until the end of all the category
names...but then I made the mistake of going ahead to the beginning of the
ticket data (which was also looking good). Couldn't seem to find anything
wrong with it, either. It JUST SO HAPPENED that all of my backorders (almost
3 years worth) of the great newsletter (Open-Apple) arrived that day...so
after spending hours with my GS and the ADB file, I went over to my father's
house (I was staying there that night) and decided to put my homework off and
read some of the issues of Open-Apple. Lo and behold, in the March issue (I
think), there was a great article on reading ADB files from BASIC...since I
didn't have access to the GS (and I did have access to homework!), I had to
wait until the next day...
Day 2
When I arrived at home after a rather easy day at school, I put the
program to good use...after more than an hour (I lost track) I had both typed
in and debugged (well, detypoed, anyway) the program (from the may issue). I
promptly ran the program on the ADB file and for record #1, I got a couple of
garbled categories (not the names, just the data) and information from record
#10! So, one of the pointers showing where the data started was confused. I
then, after hours of this and that, with a block editor looked at the first
few blocks and noticed that there were TWO report formats and not the THREE
that I knew should have been there. I remembered mention in Tom's article of
a byte in the ADB file MAIN HEADER (first 357 bytes is the MAIN HEADER then 24
categories*22 bytes/category+ X report formats*600 bytes/report format is the
only information before the actual file data), byte 38 (0 is first byte), and
therefore I checked it. It said that there were THREE report formats. I
promptly changed it to a TWO and (drum roll, please!) when I tried to reload
the file back into AppleWorks, it WORKED!
At my father's office, we use an enhanced //e (with 576K RamWorks III, a
Street Electronics BusinessCard (2 serial/1 clock), a TransWarp (never had
problems mentioned by other OA readers, and a test program that fails on some
other problem boards worked fine on mine), and a DuoDisk (with a supposedly
bug free board - had it replaced because it kept on eating my MCS every time
EA sent me a new one!). The software is AppleWorks 2.0, Applied Engineerings
Desktop Expander 2.0.1 (maybe the culprit in this case, probably in the next
bug I found which you'll end up reading about later), and RESET.SYSTEM (a
relatively current version - from Living Legends Software - adds reset
trapping to AppleWorks - shareware - I haven't paid for it though, but I will,
honest!) which is seldom if ever needed (not at all responsible for the bug, I
am sure).
What stumped me was the missing report format. When I asked my father if
he had erased it, he said, in summary, that he had activated the "Erase a
Report Format" function, but had not actually picked a format, instead he had
pressed escape to exit. I figured I better try it out. I made a BACKUP of
the file (whew!) and did just what he did. I saved it and tried to reload it
and it WOULD NOT LOAD. The EXACT same problem (counter=3, report formats=2).
So I figure this is what happens. AppleWorks 2.0 (modified by AE AWEXP 2.0.1)
for some reason has some internal counter or pointer changed when you choose
the "Erase Format" function, but BEFORE you actually choose one to delete.
ESCaping out of the function leaves that pointer or counter changed. Another
counter which keeps track of the total # of formats is still the same, but the
pointer or counter that is changed must be related to the # of formats save in
the file to disk. Anyway, I have yet to try it on an unmodified version of
Appleworks because of three reasons: First, I cannot load the file (too big)
on the //e at the office, second, I am out of blank disks at home to make a
backup of the original AppleWorks 2.0 to try it with, and thirdly, I can't
find the original fixed file (I now have a backup of it that is segmented onto
two disks since more data has been added).
=============================================================================
Another bug I found may be caused by the AE expander. When the disk had
only 1K left (all the room was taken up by the fixed file), we tried to save
using the openapple-s command and the save function from the main menu (both
of which ask you if it is ok to delete original first). It seemed to save
fine, but the disk got screwed up royally...0K left, AppleWorks hangs when you
try to load the file, and if you delete the file, the disk has a screwed up
bitmap and maybe more buggy directory info (haven't checked...haven't wanted
to!). I tried reformatting the disk, saving to the disk (ok), then saving
again (which prompts for "Ok to delete original) and got the buggy results
again. What I figure is the the Expander thinks the file has become a
segmented file (only if you delete the original) and does something to it, but
ProDOS or AppleWorks doesn't agree or something is buggy on a marginally
pre-segmented file save (almost ready to be segmented, but not quite). We
found a work around, though. We delete the original (5. Other activities,
4. Delete a file), then save it...and it works fine...(the file has grown and
is now actually a segmented file, but we still delete both of the segments
before saving just to make sure nothing happens...we also have a recent backup
OUTSIDE of the office (at my house, actually) so that it doesn't get used or
erased). Anyway, something weird is going on here...I'm pushing my father to
get a hard disk and that will probably get rid of bug #2...
=============================================================================
Anyway, I would really like to thank Tom Weishaar (I really had a problem
spelling your name! But, no matter, you'll probably have a problem
pronouncing mine, at least with a straight face...hahahahaha!) for his
information (I'm going to get all the header information from one of the
sources you mentioned) and his program and his terrific newsletter! Also, Mr.
Lissner for his great program (which probably is not at fault in this case),
Applied Engineering for their great peripherals and software (though I think I
may have found a couple bugs...biggies too), and some other local computer
users who offered their help to me in this crisis...
Brendan Gallagher Hoar
1641 Mount Eagle Place
Alexandria, VA 22302
(703)998-8657/8032
Able to be reached by modem at
[The Apple Pack BBS] (User #5)
The East-Coast GBBS support board/SysOp Ron Gabbert
(703)370-4223
-OR-
pro-novapple (bhoar@pro-novapple)
Northern Virginia Apple Users' Group
(703)352-5842
P.S.
Though it doesn't really seem to make a difference in the computer world
and especially the world of telecommunications, I am 17 years old and a
senior in high school.
P.P.S.
Acronyms...a necessary evil. I just realized, while writing this
letter, that ADB can mean two things.
AppleWorks Database File - in ProDOS directory listings
Apple Desktop Bus
*** This letter can be used in whole or in part
(even summarized) for whatever the reader wishes ***
------------------------------------------------------------------------------
P.S. There was a recent article in Open-Apple about this bug (well, I got the
issue 2 days ago...its 11/29/87...and it wasn't an article, but a letter)...it
just touched the surface, by saying that somehow the pointer got screwed up,
but the person didn't know why...they'll know soon...
bhoar@pro-novapple