Carl,
1) Question & Answer (by Symantec) has been used by the Council since 1987
to track names and payments. It is a "flat," file management program that
has many good features. The Council used it to print (& sort) labels and
that's about all. I mentioned that running on DOS v.3 (without Windows) it
is fast and stable. Every record has both a name and payments tied to a
unique ID number.
2) The records, since it was a flat file, originally had no ID numbers. I
added a field myself (as well as a Record Type) prior to importing into
ebase. The program was set to add a sequence of numbers beginning with 1,
incremented by 1 as values for the ID fields.
I did not confirm, however, that ALL the records had Legacy ID's before
importing into ebase. There were more than 2000 records and this will be
labor intensive. However, will do.
3) Since Q&A is a "flat" file, your assumption is correct that I just gave
the 1% of names records that did not match ebase new Legacy ID numbers
beginning with the next higher number than the highest Legacy ID number.
This was the edited Legacy names file that I imported into ebase before
importing corresponding payments.
*Should I have also reset the Record Number index in ebase in a manner
similar to the way you do it when you upgrade from ebase v.1.0.2 to
v.1.0.3?*
4) >Do you know how you got dupes in the 1% that did not have matching
>payments? That is, were they dupes in your legacy data?
No, I couldn't discover the reason why I got some dupes in the 1% that did
not have matching payments in ebase. (Or, in other words, records in
ebase that had numbers, but numbers that did not match the numbers in
Q&A.) There were 4 dupes in the legacy data that were identified by the
ebase import routine and these 4 were deleted as required before
importing.
I had to do a lot of editing of the Q&A payments files before importing.
The Q&A dates of payments, had been entered vertically, grouped by year,
as text fields (inconsisently as JUL/JULY, AUG/AUGUST, SEP/SEPT, etc.).
Thus the text value of every date field of every payment record (there
were over 4,000) had to be searched and replaced by generic 07/15/96,
08/15/97, or 09/15/98, etc. before the payments could be imported into
ebase. I know some import errors resulted from sleepiness during this
procedure and maybe more than I expect.
I still would like to get 1996 through 2000 records straight in ebase
before tackling 2001.
Thanks for your comments, Carl. They've helped me refine the problem in my
own head. Perhaps you would comment on the question I ask in 3).
Henry Bookout
North Fork Environmental Council
POB 799
Mattituck, NY 11901
[EMAIL PROTECTED]
On Tue, 1 May 2001, Carl Paulsen wrote:
> Henry,
>
> I remember your problem but am hard put to troubleshoot too much long
> distance as I don't know that I fully understand all the issues. I'm
> also not familiar with Q&A... so let me ask a question or two:
>
> 1. Is your Q&A database a "flat" file or a relational database (of
> several files)? If relational, did the payments that didn't have a
> matching record number work properly in the Q&A database (in other
> words, did they match up with the proper name in the Q&A database)?
> Check this carefully, b/c if a name record was deleted that had a
> payment associated with it, you could end up with orphan payment records
> with no associated name, and this could cause the problem. If "flat",
> then you probably don't have "orphan" payments and this explanation
> doesn't work.
>
> 2. Before importing your data, did you confirm that ALL of the records
> had legacy ID #s for both the names and payments?
>
> 3. How did you match the 1% payments that you gave new legacy IDs with
> the correct names in the ebase names file (these new ID #s would have
> been different from the legacy ID #s in the names file, and ebase
> wouldn't know which names records to match them to)? If your Q&A
> database is a "flat" file (not a relational database of several files),
> then I assume you just gave these records new unique numbers and
> re-imported, true?
>
> 4. Do you know how you got dupes in the 1% that did not have matching
> payments? That is, were they dupes in your legacy data?
>
> That's about all I can do for now, and I may be reaching the limit of
> what I can do via this list. Let us know what you find out and we'll go
> from there.
>
> Carl
>
>
> Bookout wrote:
> >
> > Carl,
> >
> > You tried to help with this some time back. Since then I've done some
> > homework.
> >
> > In an attempt to edit our legacy Question & Answer legacy database, I
> > deleted
> > records that showed no payments between 1/1/1996 and 12/31/00. The intent
> > was, also, to manage, first ,in ebase those records that were static and
> > complete before attempting, second, to update ebase with evolving year
> > 2001 records:
> >
> > 1) In Q&A, the found set that showed no payment in amount fields (retrieve
> > specification, =, "equal to nothing") '96 through '00 was deleted.
> >
> > 2) The remaining records (showing payments '96 through '00) were exported
> > (cdv).
> >
> > 3) Legacy records for these years and their record numbers were imported
> > into ebase, names first, payments second--each with legacy ID numbers
> > mapped appropriately in ebase.
> >
> > 4) About 1% of 1500 payment records were designated by ebase as having "No
> > Matching Payment Number."
> >
> > 5) A careful study of this rejected set of 1% of the payments that did
> > not "match" revealed no obvious reason why they didn't (except for several
> > records in Q&A that were lacking ID numbers).
> >
> > 6) In an effort to bring things into line, the individual records in the
> > 1% set were given new legacy ID numbers sequentially to the largest
> > number in Q&A and imported again. (Some of the records were ebase dupes,
> > some were not. The dupes were deleted on import.)
> >
> > 7) Fearing to leave the familiar too soon, year 2001 new members and
> > payments have been entered into Q&A* rather than directly into ebase and
> > then
> > an attempt to update ebase was made by exporting and importing just the
> > year 2001 records.
> >
> > 8) The assumption that this import would bring things into line proved to
> > be mistaken.
> >
> > 9) No-Matching-Payment-in-ebase messages are still generated when
> > payments are imported and there is still no apparent reason for the cause.
> >
> > 10) Frankly I am confused and am to blame for anyone I have confused.
> >
> > 11) Is there any orderly way to make record numbers in the Legacy database
> > that don't have Matching Record Numbers in ebase match?
> > ---------------------------------
> > *Q&A is not just familiar. We're considering using it as a primary record
> > and backup for names and payments. It is a DOS program, running on DOS
> > v.3.1 on a 436 machine. It is faster than ebase on the machines that we
> > use and is never corrupted or crashes, usually not even if you close it
> > the wrong way. The ebase import routines for cleansing name and payment
> > information implement Q&A beautifully and, of course, ebase's other great
> > features are incomparable.
> >
> > Henry Bookout
> > North Fork Environmental Council
> > POB 799
> > Mattituck, NY 11952
> >
> > [EMAIL PROTECTED]
> >
> > ------------------
> > Reminder to each recipient: To change your list account preferences, go to
> > http://email.sparklist.com/scripts/lyris.pl?enter=support and enter the email
>address you used to subscribe to the ebase support list:: [EMAIL PROTECTED]
> >
> > To unsubscribe send a blank email to [EMAIL PROTECTED]
> > ---------------------------------------------------------------------
> > ebase - Relationship Management for Nonprofits, http://www.ebase.org
> > ---------------------------------------------------------------------
>
> --
> Carl Paulsen
> New Hampshire Rivers Council
> 54 Portsmouth Street
> Concord, NH 03301
> 603-228-6472
> 603-228-0423 Fax
> [EMAIL PROTECTED]
>
> ------------------
> Reminder to each recipient: To change your list account preferences, go to
> http://email.sparklist.com/scripts/lyris.pl?enter=support and enter the email
>address you used to subscribe to the ebase support list:: [EMAIL PROTECTED]
>
> To unsubscribe send a blank email to [EMAIL PROTECTED]
> ---------------------------------------------------------------------
> ebase - Relationship Management for Nonprofits, http://www.ebase.org
> ---------------------------------------------------------------------
>
------------------
Reminder to each recipient: To change your list account preferences, go to
http://email.sparklist.com/scripts/lyris.pl?enter=support and enter the email address
you used to subscribe to the ebase support list:: [email protected]
To unsubscribe send a blank email to [EMAIL PROTECTED]
---------------------------------------------------------------------
ebase - Relationship Management for Nonprofits, http://www.ebase.org
---------------------------------------------------------------------
