Unfortunately, I thought of something else significant after making that post, which I’d also like to ask you about.

I considered this some time ago, and rejected it in favour of the email backups option I added, but I’m again considering adding an option to backup to “the cloud”, i.e. remote Internet-based storage. It might be on my own web server, or I might use a service like Amazon’s S3 (Simple Storage Service).

The idea would be that as an option, following every regular backup, an encrypted version of your backup would also be sent to the online storage. Obviously this would slow things down, depending on your Internet speed and the size of your database backups, but it would give an additional enormous level of security for your backups.

One big concern would be distinguishing everyone’s backups from everyone else’s. My thought is that the first time you went to use an online backup, a special guaranteed unique ID would be generated for you, and stored in your database. That key would be used to identify your backups online. It would also be transmitted to me (the first time) so that if you somehow lose everything on your computer and all local backups you have made, you can request the key from me, re-enter it into a new copy of the program, and then retrieve that online backup.

There are a couple of options for how the encryption could work. Obviously, it would have to be based on an encryption key.

One option is to just have you provide the key, and also store it in your database for re-use each time you do an online backup (or restore). That’s like how the current email backups work – you provide the key, and if you forget it, you are completely out of luck. It would be the same with this. (I would not suggest that you send me the key – I should have no access to your data.)

Another option would be for me to have a secret way of generating the key from your unique ID, and just use that generated encryption key.

Both methods are succeptible to cracking (though with significant difficulty!). If someone knew your unique ID, they could enter it into a copy of DONATION, and get back your encrypted database. At that point, with the first option (you provided the key), standard methods could be used to guess obviously bad keys (like “password”!) which some percentage of users always use. With the second option (I create the key in a secret way from your unique ID), a very skillful programmer might be able to reverse engineer my program to determine what my secret way was.

And of course, anyone with access to your current database could also get access to your backups stored online. But that doesn’t seem like a big concern, since they already have access to your current database!

There are also privacy concerns in terms of national legislation like the US Patriot Act, which as I understand it gives the US government the right to inspect any data that is stored in the USA, and to demand any required encryption keys from the data’s owner. Apparently there is somewhat similar legislation here in Canada, and Canadian privacy legislation may forbid the storage of such information in the USA. One option with Amazon’s storage is to store the data in their facility in Ireland. I’m guessing that could cause slightly longer transmission times, but might address this issue. Or perhaps users just aren’t that concerned – generally the IRS in the USA or the CRA in Canada would have the right to audit you, including seeing any donation information, anyways!

My web server is in Vancouver, so storing the data there (or in some Canadian cloud storage provider) would at least eliminate the Patriot Act concerns.

Because there is a cost to online data storage (though it’s quite minimal!) I don’t see retaining unlimited numbers of backups from each user online. Perhaps the last 3?

Any thoughts about all of these points, and the general idea? Many thanks!

I’ve had three or four users relatively recently report missing data within the current year, like “I’m missing all of June and July’s donations, but the ones after that are there”.

Given that there is no feature in DONATION that could possibly mass delete donations like that, the only possibility I can imagine for a situation like that is that at some point in August say, they accidentally (or on purpose, but not understanding what they were doing) restored a database backup from the end of May, didn’t realize that lost them their June and July data, and then just continued data entry from there.

So, I’m working on ideas for some changes to make this less likely.

The first has to do with backups. Currently if your database is the default one, DONATION4.DB, the default backup name you are offered is DONATION4.DB.GBK. You can change that (as long as you leave the ending of “.DB.GBK”), but I’m sure most people don’t.

My idea is to change the default backup filename to be based on the current date, e.g. DONATION2011-12-07.DB.GBK for today’s backup (on December 7, 2011). It could still be changed if desired.

There are two advantages to this. The first is that it will be obvious how old a backup is, that a user is trying to restore (as long as they figure out the YYYY-MM-DD date format, I guess!). The second is that unless the user does something about it, they will have a bunch of backups stored, from all different dates, and each backup will not overwrite the previous one that was stored in the same location.

However, that last point is also a potential disadvantage, as those multiple backups could start filling up whatever storage they were storing it in, e.g. their hard drive or a USB memory key. However, for most users a backup is at most a few megabytes, so it would really take a long time for this to be an issue given the large size of today’s storage.

One option would be to do what some other programs do, and have an option to keep only the last N backups, where they specify the number N (like, last 10 backups). But personally, I think you never know how old a backup you might need. So I’m not sure whether this is a good idea or not.

There could also be an option (on the same window as the one for changing the Backup Reminder Frequency) to go back to the old naming convention, leaving the date part out of the backup filename. But I’m not sure that’s a good idea, as the advantages of the new naming are significant, and the users can always erase the date part from the filename each time they do a backup, if they feel strongly about it.

If I added one or both of the options mentioned above to the Backup/Restore -> Backup Reminder Frequency window, I’d probably rename that menu option to Backup/Restore -> Backup Options.

Now, on to restores. What I’m thinking is that when you go to restore a backup, the program will first open up that backup and find the latest donation date in it. It will compare that to the latest donation date in your current database, and if the backup’s data is older than your current data, it will give a message about it, including stating what each of those two dates is. If the backup data is at least one month older, the message could also say something like “You are about to restore data that is N months older than your current data.” And then of course ask whether they really want to do the restore.

Any thoughts about these changes, and the possible options mentioned above (let them go back to the old backup naming without the date part, and let them specify a maximum number of backups to store in the same location)? As usual, you can Comment on this post to give me your thoughts, or just email a reply. Thank you in advance!

If you have a moment to try it out, you can find the beta test version of that at http://www.software4nonprofits.com/pretest.htm.

Other than “what do you think of that”, I do have one specific question for you. The exact same Find Donor window is used by the One Date Batch Entry window as by the main window. One thing that is now a bit weird about that (and which I mention in the revised Help page for Finding a Donor) is that this means you can search by Phone # and Address  on the One Date Batch Entry window, despite the fact that those fields are not displayed.

My initial thought is that there is no big downside to leaving this in, and some users with unusual data (like the one I created this new feature for) might actually find it useful. But an obvious small downside is that it’s potentially confusing, and having searched by Phone # or Address, you still have to check that the one it found is correct. And you may not be able to check that successfully, if you say have two donors named “Smith, John”, with different phone numbers and no envelope numer. You would just have to trust that the program found it correctly.

There are actually a few further improvements in Find Donor in this version, beyond the new fields. The first is that you can search on more than one of the four fields (Name, Number, Phone and Address), and choose between joining any conditions on those fields by “and” or “or”, with a “Use Or” checkbox. (It defaults to being unchecked, so “and” is used.)

The second improvement is that for the fields other than the Number (member/envelope #) field, you can use the “%” symbol in a search string to represent “anything”, i.e. any number of characters. For instance, “Cooper%Dan” will find “Cooperstock, Daniel” in the Name, or
“123%5678″ will find “(123) 111-5678″ or “111-123-5678″ in the Phone number.

Finally, for donors with both a Business Name and a Last Name and First Name filled in, the Name field will search on either of those fields. (Previously it would search only on the Business Name, for donors that had one, or on “Last, First” for all other donors.)

As usual, please leave a Comment on this blog post, or email me, with any testing results or thoughts on these changes. Thank you!

There are a few reasons I’m thinking about dropping those buttons from the reports-viewing window:

• I have hardly ever heard from anyone who uses them.
• The most likely reason to use them is to add a custom sort or filter into the SQL itself, so that it can be retrieved and re-used later. But that need will be satisfied by the features of the new Memorized Reports.
• There are a lot of buttons on that window – if I add a “Memorize” button, dropping two other buttons leaves it less cluttered.

Having said that, there would still potentially be complex things that could be done with the Save SQL and Load SQL buttons on the reports-viewing window that could not be done with only Sort and Filter. However, in most cases those same effects could be reasonably replaced with reports/SQL created through Custom Reports, or directly through Database -> SQL Select.

So please get back to me if you have ever used this feature and do not think it would be sufficiently replaced by the ability to memorize reports with custom sorts and filters.

Thank you.

The current release of DONATION, 3.37b, includes the conversion routines. When you start DONATION for the first time, if Membership Plus is installed, you will be prompted to convert your data from it. Or, you can convert later with the Database -> Import -> From Membership Plus menu option. I haven’t made a general announcement to all existing DONATION users of this new version, because it is more of interest to new users than existing ones.

As well as converting the basic organization info, it converts the Membership Plus members to donors, funds to donation categories, and contributions to donations. The last two years of contributions are converted.

If anyone is using the PAR service, you may already be receiving with your monthly information about the donations they are processing for you, a text file containing details of those donations. (This is as opposed to a readable report on them.) If you aren’t receiving the text file, you can request it from them. If you have that file, you can now import it directly into DONATION, as long as all of the donors have envelope numbers that PAR knows about.

If you want to try this, it is in the beta-test version 3.36b Beta1 available at www.software4nonprofits.com/pretest.htm. As usual, if you do test this, please let me know how it goes!

The other interesting news is that I have recently completed what is basically a purchase of the business of a smaller competitor – another one-man church software business, but he is 71 years old and ready to retire. The software is The Church Assistant from Wincrafters.

The way the deal works is that he has written to all of his about 300 users, informing them of his retirement, that he will be stopping selling The Church Assistant immediately, and stopping supporting it in 6 months, and encouraging them to switch to DONATION (which has been enhanced to convert much of their data after installation). I’m offering them DONATION at a 50% discount for the first 6 months, to make this a less painful switch. And I also get his mailing list, so I can follow up further with those who haven’t switched. If course, there’s a cost to me - in essense, he gets a 50% commission on all sales to his former users, for the first year. Hopefully this will be profitable for both of us, and in addition, it stops his users from being left without support, on an orphaned product, after his retirement.

There is a special website for Wincrafters The Church Assistant users considering switching/upgrading to DONATION, at http://wincrafters.software4nonprofits.com.

If you have any comments, as usual please just Reply to this blog, or email me if you don’t want your reply to be seen by others. Thank you!

I’m trying to figure out whether it might be possible to have a built-in importing routine for basic data from Membership Plus, like organization info, donors, donation categories and donations. (I’ve just done one for another application, which I will write to tell you about shortly, and that – along with an inquiry from a current Membership Plus user – got me thinking about this.)

Even if you have an old Membership Plus database and don’t feel you can share it with me, if you could tell me the filename (or filenames) of the database, and/or possibly let me do a remote control session on your computer to look at the files myself, that might be helpful.

Thank you.

I just received a call from a potential user, who has donations where someone has bought a brick for $25. The value of the brick is $15, so the receiptable (tax-deductable) amount is only $10. But they want the receipt to somehow reflect all of that.

For Canadian users, the Canada Revenue Agency has very specific ways this type of gift is to be receipted, and DONATION handles that using the Eligible Amount field and special wording on the receipts.

But for U.S. users, I’m afraid I’m really not clear about whether there is any standard way that this should be represented on a receipt. You can use the Eligible Amount field, but the receipts by default show only the total amount ($25 in this case). You can edit the mail-merge receipts to show all three amounts. They are: Eligible Amount – $10, Advantage Amount (what they received) – $15, and total Receipt Amount – $25. But I don’t know what that should look like.

Any suggestions (specific, please!)?

Thank you.

• Add a Memorize button to both the SQL Select window and the Report-viewing window.
• In SQL Select, Memorize memorizes the title, style (Normal/Grid), orientation (Portrait/Landscape) and the SQL.
• In the Report-viewing window, if the report came from a SQL Select, Memorize memorizes those same things plus the Sort and Filter. If it came from a built-in report, it memorizes the underlying report’s internal name (called the DataWindow), the Sort and Filter, and the underlying SQL for the DataWindow (which might have been edited using Save SQL and Load SQL). (However, check if it is composite report like Reports -> One Date Donation -> Summary, in that case can’t memorize it, no point, can’t sort or filter them! Actually, Sort and Filter should be disabled for such reports, they are useless.)
• Save to a file in a Reports subdirectory under the program’s Data Directory, named something.rpt.
• For saving, have a window with an input field for the report’s name (without “.rpt”) and a list box of existing memorized report names. If you click on a name in the list box, it puts it into the input field.
• When saving from the Reports window, if it is displaying an existing memorized report, default to re-saving it with that memorized report’s existing name.
• Add a “Memorized Report” menu option to the Reports menu, at the end under Custom Report. It brings up a list box of the existing memorized reports (without .rpt), you select one and click Run to run it, it immediately displays the report.
• Max report name length 50 (excluding “.rpt”, which the user never sees unless they use Computer or My Computer to look in that directory). (Is 50 a good maximum?)
• How to further edit an existing Memorized report that came from SQL Select? I guess have a checkbox on the Memorized Reports window for “Edit first in SQL Select window”, which would only be valid for ones saved from there (or saved from the Reports window if they came from there).
• When saving a memorized report that you are editing in the SQL Select window, again default to re-saving it with its existing name.

Any thoughts, comments or suggestions? Please  post them as a Reply to this blog post.

This bug has been fixed by version 3.33c, which I uploaded to the regular web site (not just as a beta version) yesterday. You can upgrade to it with Help -> Check for Updates.

Because of the impending holiday season, I’m not planning on sending an email out to all users about this version until early in January. For those of you for whom this time of year is special, best wishes for the Christmas season!