Virtual Enrollment Party

Well, once again we have new postal regulations in terms of bulk mailings. You're not going to be able to use the standard Blue Ribbon mailing labels if you want to use bulk mail rates.

THANKS to Mary Kay Litzel, Steph Erpelding, and Anjanette Treadway, there's now a new document on the Blue Ribbon Helpsheets webpage that will help you get information OUT of Blue Ribbon, INTO Excel, and then ONTO labels, either using Microsoft Word 2003 or 2007, or Filemaker Pro. The directions for Word are noticeably more complete than Filemaker, but my latest "beginner" Filemaker manual has complete instructions for creating a labels layout within that program if you need more info.

The short version of the story is that when using bulk mail, you now either have to include "Return Service Requested" under your RETURN address (and pay for those returns) or include "Or Current Resident" in the address. It's that second option that won't work with the Blue Ribbon mailing labels setup.

Again, thanks to Mary Kay, Steph, and Anjanette for their help with this project. The resulting document is a whopper for a HelpSheet--6 pages--and much of its content (and helpfulness) comes from those 3 people. I'm definitely not a mail OR mail-merge guru, and I really appreciate them sharing their time and knowledge!!

Posted by Becky at 01:47 PM | Permalink | Comments (1) | TrackBacks (0)

I know that not all of you use scripts that import data from another file, so if you don’t, this is going to be useless info. But if you DO, keep reading in the spirit of “It’s less painful to learn from someone ELSE’S mistake.”

When you set up an import script, you match up the fields in the order in which they should match up for the import. The annoying part for me has always been that I couldn’t “re-order” the fields on the left side of the import screen—the ones from the “sending” database. They always seemed to be in some sort of random order, not alpha.

Today I learned that the order is not at all random. It’s specifically in the order in which the fields were originally created.

So, what happens when you DELETE a field (most painfully an early-created one) from that source database? Well, sports fans, all your import scripts that depend on that database have their import order changed. The left side of the import screen changes order, shifting up to remove the space taken by the deleted field. The RIGHT side (receiving database) fields DO NOT change, meaning that they no longer match up where they used to. An “imaginary” example would have the HorseTotal going into the Grade field. Badbadbad.

And even worseworseworse, once that original field was deleted, it doesn’t do any good to go back and put it back in. Since it’s now been the LAST created field, it’s just going to plop itself at the bottom of the import list. So the only solution is to go through every script that includes an import step and manually reorder the import order.

The better solution would have been to RENAME the no-longer-necessary field, rather than deleting it. I did not learn this by reading a book or thinking logically through this, but through bitter experience (probably the best way to remember at my age). If I had it to do over, all my unnecessary fields would have been renamed to ZZoldWhateverTheyWere so that they could be easily identified as no longer necessary, but they’d have stayed within the file. I seriously hope I remember that next time!!

Posted by Becky at 09:28 AM | Permalink | Comments (0) | TrackBacks (0)