>From a fund raising/stewardship stand point I cannot even begin to tell you what a
>bad idea I think it is to "prune" payment data from your database. This is
simply valuable data you do not want to lose. For example, one statistical indicator
of potential planned giving prospects is a pattern of consistent small
donations made over a long period of time. Removing this data, or making it difficult
to retrieve, could make data mining ineffective.
Removing "inactive" donors is also not a good idea. Inactive donors have been know to
make unexpected bequests. Sometimes bequests are challenged in court by
unhappy surviving family members. This has actually happened in my career. We were
required to substantiate our long relationship with the donor to prove that
he was not unfairly influenced before his death to make the gift. Fortunately, this
was not difficult, because we had very good records. Some of the records we
submitted were from our database.
Cumulating gifts annually could also create false conclusions regarding a donors
ability to give. Though generally people are not insulted when they are asked
for a far bigger gift than they are capable of making, it isn't a very effective use
of staff or volunteer time.
Even if your organization isn't currently actively targeting its donor base or data
mining, that doesn't mean it won't do so in the future. Chances are it will
at some point, if it wants to grow. Having reliable, accurate records will make the
job easier when it is undertaken.
This sounds to me like a serious problem with ebase. I'm very disappointed to hear
about it. It would seem to limit the long term usefulness of this program for
fund raising purposes.
Rainie Jueschke, CFRE
Director of Development
S.C. Fair Share
Walt Daniels wrote:
> > So I've never personally seen the "file is damaged" any time
> > except immediately upon opening a file. Perhaps there's a
> > problem in some part of the file that's not being caught by the
> > checksum (why, I don't know) and only triggers the error when
> > that part is put into use.
>
> I have, just a couple of days ago. I opened the file with no problem. A bit
> later after not having made any changes, I did a find for duplicates (with
> !) and it said that the file was damaged. Two of us had each taken home a
> copy of the running system and were independently working on finding ways to
> remove some persistent duplicates. My copy had the problem, his did not and
> the original did not. Very curious. It is a large payments file (150+ meg).
> The only thing significantly different that I can guess is my machine has
> more memory and is faster than the other two. A few days later I brought
> home a version that was only slightly different and it has no problems. I
> don't even want to think about how to chase this bug.
>
> The largeness of the file brings up an iteresting issue. The payments file
> for everyone is going to grow every year and will eventually get to be a
> problem. Perhaps it is time to start thinking about strategies for pruning
> it occasionally while retaining some ability to query past history. The kind
> of thing I am thinking about is retaining a total by year for each member
> but deleting all the individual transactions that were made that year.
> Perhaps such historical information should be in a separate file and perhaps
> not even open unless you want to do historical queries or do the pruning
> step. I have less need for a similar historical file for names but some
> might. I wouldn't mind deleting non-active people from names, but still be
> able to go back to them every few years and try to convince them to become
> active again and if they do, reinstate their past history.
>
> ------------------
> 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
---------------------------------------------------------------------
