Hello Michael, Happy to try to answer your questions. See replies below.
At 04:34 PM 4/1/02 -0400, you wrote: >A couple of questions about import into ebase2 using the External Import >Wizard, how data aligns and similar things. >I am working with data from a user-created database, not a previous version >of ebase. > >(1)Can I assume that Pledge can be equated to PAC (= pre authorized >chequing)? This sounds like a process question, not an ebase question per se. I assme that you're referring to Log Items of Class=Pledge? If so, I'm not sure how this is an import issue. Or is this a general ebase question? Could you give us a bit more context here? >(2)If I intend to follow your suggestion for importing from Excel with >matching column headings, >presumably I only have to include columns for which I have data? Yes. Excel is smart enough to know which cells have data. And FMP is smart enough to use this range when it imports from Excel. Do note that the ability to import from Excel is not available in the Runtime version of ebase - you need to have Filemaker Pro. (This is an FMP issue, not particular to ebase.) >(3)I have some/many records which don't have data in every field. >Which fields are considered essential? That (like many, many other things in ebase 2) is mostly up to you. The only thing that is required in a Contact record is a name (First/Last Name for individuals, Family Name for families, Org Name for organizations). The ContactID field is also required, but this is generated automatically so you don't have to supply it. Everything else is not required in the literal sense. However, you may find that your org's activities in effect demand certain data. As far as import goes, as long as each Contact record has a name, you should be able to import whatever you have. >(4)If my original database didn't have a Name1: Prefix, Name1: Middle, or >Name1: Suffix, >but I have an entry FirstName = (Dr. Samuel D.) LastName = (Winchester Jr.), > >presumably it would be preferable for me to separate out the Dr., D., and >Jr. to give five fields rather than two, before importing. >Does your Preview Area provide a mechanism for dealing with this? You have several choices here. The first, and best, is to use the Name 1:FullName field when importing instead of Name1:First and Name1:Last. The Import Wizard will then do its best to parse out the name into component fields from the data given. I did a test, and it parsed both your examples correctly. (There's no guarantee that it will always parse the names how you'd like them to be parsed - you'll need to do it yourself for that - but it is capable of some pretty reasonable guesses.) In your case, you'll have to first combine your FirstName and LastName fields before feeding it to the Import Wizard as FullName. This should be easy to do in Excel or any database program. Let me know if you could use help with this part. Alternatively, you could: * Separate your names into component fields before importing (using Excel or database, etc.) * Import as FirstName and LastName, then separate out by hand in the Preview Area. (Or, if you're an experienced FMP'er, and can come up with rules for how to separate names, you can also do Replace commands in the Preview Area and enter calculations for how to parse the names.) >(5) >I occasionally have records where we should have had two names per >household, and they've been fudged in various ways. >E.g. >Luke/Janice Pelot/Brown >Brian & Lianne Giswold >Should I extract these data from my major dataset, clean them up, then >import, Yes. The way to do it, as you're probably already aware, would be to have Luke Pelot as Name1 and Janice Brown as Name2. If given to the Import Wizard in this form, it will automatically split that record into 3 contact records: Luke (Individual), Janice (Individual), and a Family record linking the two. >or is there something within the import tool which knows how messy my data >could be, and will help me overcome the problems? This is something we've slated for a future upgrade. The difficulty is relibably knowing what constitutes a compound name, and how to reliably parse it. For now, it's up to you. >(6) >If I have data which doesn't align in an obvious manner with your import >fields, perhaps I can move it to either logfields or profile notes. >Could you be more explicit about how logfields and profile notes are to be >interpreted by the newbie and ebase2? Yes, this is definitely needed. I'm currently working on some further help/documentation that will be released as part of the ebase 2.01 upgrade (due in April) that will cover some of this. In the meantime: You are correct in your basic understanding. If there was a field in your source db that is not directly represented in ebase, there are several options as to how to import/represent it. THe basic method should be to turn it into a Log item, which is done by importing it to a LOGFIELD (or multiple LOGFIELDs) and then defining the Log Item in steps 5 and 6 of the Wizard. See Help from these Wizard steps for further details. The Log item creation routines in the Wizard are pretty flexible, so there's lots of ways that you can use source data to create items. See what you can come up with, and feel free to write back with specific questions. Profile Note is a single field in each Contact record, more or less equivalent to Memo in ebase v1. It is meant to hold general notes about the contact, but is not meant to be a categorical field (i.e. a field you would do finds on). Multiple ProfileNote slots are provided in the Import Wizard simply because we might want to include text from multiple source fields. IF you provide data in more than one of these slots, the text is simply concatenated together. So I would put it in ProfileNote only if it really is just a textual note (and nothing that categorizes or defines the record) and it's not something that will need to be reported on or used to find records. Otherwise make it into a Log item (import it to a LOGFIELD). >Actually definitions for many other fields would be useful. >I can guess many of these, but to avoid guessing wrong, definitions from the >experts might be useful. Again, some further definition will be in the new documentation. >E.g. GMT and TimeZone. >I would guess that timezone might be something like EasternStandardTime or >EST, and correspondingly GMT would be +/-5, but which? AFAIK (and Bob, Cliff, plz correct me if I'm wrong) these fields are (again) up to you. I don't believe there's anything built into ebase that needs these in a particular format. There are no built-in consequences. This flexibility is intentional. If your group customizes ebase and build reports/processes that use these fields, then they may need to be in a particular format. >e.g. >Add By ... Is this the person/user who adds the user to the database? Yes (if you meant to say 'who adds the record to the database') >Add Date ... date log entry created? Date the contact record was created - 'log' has a particular meaning in ebase, not sure if this is what you meant or some more general meaning. >E.g. >Family Name ... Not to be confused with Name1: Last, >I should probably use Name1:last ? Oh yeah, good point. I never thought about how potentially confusing that is. Yes, FamilyName is different. It's used when you're creating a Family record. THis is a new record type in ebase 2, and takes the place of Householding in ebase v1. It's a record that represents a family as a separate entity from the individuals that are its members. The individuals may also be recs in the db, and may (should) be Linked to the Family, but the Family is (can be) a separate record. Use Name:Last when importing an individual. >That's enough for now. No worries. Happy to help, and this is good feedback for us, to see what does and does not make sense to you. Please write back if you have further questions. Matthew Matthew Scholtz Non-Profit Technology and Database Consultant Bellingham, WA ebase v2 Dev Team > >Michael Ruxton Hydrographic Systems Analyst >(902) 426-4227 fax: (902) 426-1893 > >Canadian Hydrographic Service (Atlantic), DFO >1 Challenger Drive >PO Box 1006 >Bedford Institute of Oceanography >Dartmouth, NS >B2Y 4A2 > >Striving for excellence motivates you; striving for perfection is >demoralizing. - Harriet Braiker > > >------------------ >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 ---------------------------------------------------------------------
