Re pruning:
One client of mine has a rather large database and didn't want ancient stuff hanging
around forever. So we came up with the following policy:
Donors are kept for at least 5 years after their last donation (and this is enforced
by script on the Delete function). After 5 years, assuming other failsafes don't
prevent it, they will be deleted as part of a "mass deletion" that will happen 2 or 3
times a year. But, before each mass deletion, the entire database will be archived to
a CD that will be kept in a library. And a reference to which CD they're on is kept
in the Deleted_.fp5 file.
So if they're doing an aggregate report that only includes data from the last 5 years,
they just run it in the active database.
If they need numbers from more than 5 years ago, they just go back to the appropriate
CD.
Less slick than what you propose here, but also a lot simpler and quicker to implement.
Matt
At 09:38 PM 8/24/01 -0400, you 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
>---------------------------------------------------------------------
>
>
Matthew Scholtz
Database and Non-Profit Technology Consultant
Bellingham, WA
Also associated with NPower, Seattle
www.npower.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
---------------------------------------------------------------------
