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
---------------------------------------------------------------------
