>
>Unfortunately, most of these directions are more advanced than my
>experience with e-base. For example, how do I export my source codes to a
>new filemaker file? How do I create a new filemaker file? How do I
>create a new value list and have it draw values from the new file?
This is probably more that is possible to do through an email
exchange, given that you have used FileMaker very little. Actually, I
should ask if you have FileMaker, or are you using the ebase runtime?
You will need Filemaker to make these modifications. If you have
FileMaker, you should work your way through the user manual and the
tutorial until you are comfortable with the procedures, or recruit a
volunteer or consultant ot make them for y ou. If you don't have
FileMaker, you'll need that help anyway. It would be possible for
someone with FileMaker to make the changes to the file and put it
back into your file set.
I don't want that to sound harsher than I mean it, but the procedures
described are risky if you aren't pretty comfortable with FileMaker
and ebase. To attempt to exchange directions and questions through
the email list could be problematic.
> >
>> >I have two questions regarding source codes:
>> >
>> >1) I was wondering if there's a way in which to archive old source codes
>> >from mailings that aren't going to receive anymore responses. I'd like to
>> >do this because our source code records are continuously increasing, and
>> >it's becoming more difficult to easily discern one source code from the
>> >next, thereby increasing the potential for error in our tracking system.
>> >I've tried to streamline the number of sourcecodes that we currently use,
>> >but our old source codes are many. For example we used to track people
>> >who have attended our member canoe trips on an individual basis by
>> >location and date (eg Arrowhead Marsh July 99). Our current method is to
>> >track all of the canoe trips for the year together (eg Member Canoe Trips
>> >2001). One possible way to archive our past canoe trips would be to
>> >combine them into a single source (eg Member Canoe Trips 1999). Would I
>> >lose any data beyond the name of the source code itself if I did this? Is
>> >there a better way to decrease/archive the sourcecodes in our database?
>>
>> You would lose some information, since you still have payment,
>> action, and contact records referenced by the source codes. Another
>> way to look at the problem though, is to leave all your source codes
>> in the database, but present only a limited number for review when
> > choosing from a popup list. Jack Noll has posted a solution to this
> > problem a number of times. I have pasted directions for this
> > modification at the bottom of the message.
>>
>> >2) I could run reports for our renewal mailings more easily if I could
>> >change the order for naming my source codes so that the date comes before
>> >the campaign? This way, I could find all of the response for Q101 (quarter
>> >1 2001) in one find request rather than having to include all of the
>> >sourcecodes from Q1 (eg R1Q101, R2Q101, R3Q101...). Would this ruin the
>> >sourcecodes that are currently in use?
>>
>> Probably, but there is no reason to go to that much work. At the
>> bottom of the payments query screen is a set of fields that lets you
>> search by the components of a source code separately. You could
>> re-create that in the contacts and actions file if you need them
>> there.
>>
>> Jack's source code list solution follows:
>> ---------------------------
>>
>> There are several ways around this. Remember, value lists can be
>> either custom entries (you give the list a name and then specify the
>> different values making up the list) or their values can be drawn
>> from one or two fields in a file.
>>
>> The source code value list currently being used when you enter a
>> payment is an example of the latter; it's drawing its values from the
>> records in the solicit_ file.
>>
>> The easiest way around the problem of getting a huge list is this:
> > Create a new value list in the paymnts_ file named "Short SC List".
>> Type in the specific source codes you want to appear in the list
>> (remembering that, with custom values, you don't get the option of
>> having descriptions that accompany your codes). Then, on the entry
>> layout, attach this new value list to the source code field.
>>
>> A second option is to export all of your source codes to a new
>> filemaker file named "SCShort_.fp3". This file would only have two
>> fields: the source code and the description. Then, get into that file
>> and delete those source codes that you don't want in your short list.
>> Finally, back in paymnts_, create a new value list called "Short SC
>> List", and have it draw its values from the fields in this new file
>> instead of from the solicit_ file. The benefit here is that you get
>> descriptions. The downside is it's an extra file that you have to
>> open and maintain.
>>
>> A third way (and I won't get into a step-by-step on this one; you
>> either know what I'm talking about or you shouldn't be doing it) is
>> to create a text field in the solicit_ file named "DisplayInList" and
>> stick it onto the source code entry screen. If the field has a "Y" in
>> it, then you want the record to be in the short list.
>>
>> Next, create two calc'd text fields: SC4List and SCDesc4List. The
>> calc for the SC4List is:
>>
>> If (DisplayInList = "Y", Source Code, "")
>>
>> The calc for SCDesc4List is:
>>
>> If (DisplayInList = "Y", Source Code Description, "")
>>
>> Finally, create a new value list in paymnts_ named "Short SC List",
>> and have it draw its values from the these new fields in the solicit_
>> file. The benefits here are many: you get descriptions, maintenance
>> is easy, the list is totally dynamic, etc. The downside is iyou need
>> to know what you're doing in Filemaker to set it up. This method is
>> basically the answer to your request that we'll probably implement in
>> the next version of ebase.
>> --
>> --
>> Dave Shaw H4 Consulting
>> tel: 206-954-7526 fax: 206-625-1338
>> --============_-1206954311==_ma============
>> Content-Type: text/html; charset="us-ascii"
>>
>> <!doctype html public "-//W3C//DTD W3 HTML//EN">
>> <html><head><style type="text/css"><!--
>> blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
>> --></style><title>Re: [support] source code
>> archive?</title></head><body>
>> <blockquote type="cite" cite>I have two questions regarding source
>> codes:<br>
>> <br>
>> 1) I was wondering if there's a way in which to archive old
>> source codes<br>
>> from mailings that aren't going to receive anymore responses.
>> I'd like to<br>
>> do this because our source code records are continuously increasing,
>> and<br>
>> it's becoming more difficult to easily discern one source code from
>> the<br>
>> next, thereby increasing the potential for error in our tracking
>> system.<br>
>> I've tried to streamline the number of sourcecodes that we currently
>> use,<br>
>> but our old source codes are many. For example we used to track
>> people<br>
>> who have attended our member canoe trips on an individual basis by<br>
>> location and date (eg Arrowhead Marsh July 99). Our current
>> method is to<br>
>> track all of the canoe trips for the year together (eg Member Canoe
>> Trips<br>
>> 2001). One possible way to archive our past canoe trips would be
>> to<br>
>> combine them into a single source (eg Member Canoe Trips 1999).
>> Would I<br>
>> lose any data beyond the name of the source code itself if I did
>> this? Is</blockquote>
>> <blockquote type="cite" cite>there a better way to decrease/archive
>> the sourcecodes in our database?</blockquote>
>> <div><br></div>
>> <div>You would lose some information, since you still have payment,
>> action, and contact records referenced by the source codes. Another
>> way to look at the problem though, is to leave all your source codes
>> in the database, but present only a limited number for review when
>> choosing from a popup list. Jack Noll has posted a solution to this
>> problem a number of times. I have pasted directions for this
>> modification at the bottom of the message.</div>
> > <div><br></div>
>> <blockquote type="cite" cite>2) I could run reports for our
>> renewal mailings more easily if I could<br>
>> change the order for naming my source codes so that the date comes
>> before<br>
>> the campaign? This way, I could find all of the response for Q101
>> (quarter<br>
>> 1 2001) in one find request rather than having to include all of
>> the<br>
>> sourcecodes from Q1 (eg R1Q101, R2Q101, R3Q101...). Would this
>> ruin the<br>
>> sourcecodes that are currently in use?</blockquote>
>> <div><br></div>
>> <div>Probably, but there is no reason to go to that much work. At the
>> bottom of the payments query screen is a set of fields that lets you
>> search by the components of a source code separately. You could
>> re-create that in the contacts and actions file if you need them
>> there.</div>
>> <div><br></div>
>> <div>Jack's source code list solution follows:</div>
>> <div>---------------------------</div>
>> <div><br></div>
>> <div><font face="Palatino" size="+1" color="#000000">There are several
>> ways around this. Remember, value lists can be either custom entries
>> (you give the list a name and then specify the different values making
>> up the list) or their values can be drawn from one or two fields in a
>> file.<br>
>> <br>
>> The source code value list currently being used when you enter a
>> payment is an example of the latter; it's drawing its values from the
>> records in the solicit_ file.<br>
>> <br>
>> The easiest way around the problem of getting a huge list is this:
>> Create a new value list in the paymnts_ file named "Short SC
>> List". Type in the specific source codes you want to appear in
>> the list (remembering that, with custom values, you don't get the
>> option of having descriptions that accompany your codes). Then, on the
>> entry layout, attach this new value list to the source code field.<br>
>> <br>
>> A second option is to export all of your source codes to a new
>> filemaker file named "SCShort_.fp3". This file would only
>> have two fields: the source code and the description. Then, get into
>> that file and delete those source codes that you don't want in your
>> short list. Finally, back in paymnts_, create a new value list called
>> "Short SC List", and have it draw its values from the fields
>> in this new file instead of from the solicit_ file. The benefit here
>> is that you get descriptions. The downside is it's an extra file that
>> you have to open and maintain.<br>
>> <br>
>> A third way (and I won't get into a step-by-step on this one; you
>> either know what I'm talking about or you shouldn't be doing it) is to
>> create a text field in the solicit_ file named "DisplayInList"
>> and stick it onto the source code entry screen. If the field has a
>> "Y" in it, then you want the record to be in the short
>> list.</font></div>
>> <div><font face="Palatino" size="+1" color="#000000"><br>
>> Next, create two calc'd text fields: SC4List and SCDesc4List. The calc
>> for the SC4List is:<br>
>> <br>
>> If (DisplayInList = "Y", Source Code, "")<br>
>> <br>
>> The calc for SCDesc4List is:<br>
>> <br>
>> If (DisplayInList = "Y", Source Code Description,
>> "")<br>
>> <br>
>> Finally, create a new value list in paymnts_ named "Short SC
>> List", and have it draw its values from the these new fields in
>> the solicit_ file. The benefits here are many: you get descriptions,
>> maintenance is easy, the list is totally dynamic, etc. The downside is
>> iyou need to know what you're doing in Filemaker to set it up. This
>> method is basically the answer to your request that we'll probably
>> implement in the next version of ebase.</font></div>
>>
>> <div>-- <br>
>> --<br>
>> Dave Shaw H4
>> Consulting<br>
>> tel: 206-954-7526 fax: 206-625-1338</div>
>>
>------------------
>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
---------------------------------------------------------------------
</BODY>
>> </html>
>> --============_-1206954311==_ma============--
--
--
Dave Shaw H4 Consulting
tel: 206-954-7526 fax: 206-625-1338
