Jump to content

Scottish

Members
  • Posts

    18
  • Joined

  • Last visited

Scottish's Achievements

Apprentice

Apprentice (3/14)

  • First Post
  • Collaborator
  • Conversation Starter
  • Week One Done
  • One Month Later

Recent Badges

0

Reputation

  1. Figured it out Enthusiast. Thanks again for your help. Scottish
  2. Got it. Thank you so much! Scottish BTW, Is it possible (or advisable) to incorporate the two? A value list generated from the field along with the custom value list already built?
  3. G'mornin' Enthusiast... I felt that your statement, "What you put in is what you get out" not only overlooked the point I was making (that I inputted data incorrectly intentionally to test field behavior after I formatted the field as you suggested) but also implied that I didn't get it. Your suggestion for me to define the value list to use values from a field also implied that I was referring to a field reference (whereas I was referring to how the primary field was set up). My trailing (light-hearted) comment "Don't be a snot" was my way of gently shedding light on your tone, which felt unjustifiably critical. Of course I realize that you (people) are trying to help; and I accept it graciously. THANK YOU! I am unable to zip you a sample DB at this time. How 'bout let's just start over by simply re-defining the initial question... The question remains, "Can I expand text parameters in a custom-defined value list to exceed beyond 30,000 characters?" "...If so, how?," "...if not, "why?"
  4. "If you incorrectly type the company name in a Custom Value List the incorrect spelling would show in that value list also. What you put in is what you get out." Perhaps you over-looked the part where I described how I had entered a company name improperly INTENTIONALLY to test something. After reviewing your reply one more time, it occurred to me that your perspective is secondary or after the fact (reference to a field that is ALREADY formatted). My perspective is the initial field; and I affirm (after doubting myself and reviewing my options over once again), that I indeed want the field formatted using a custom-defined value list...the purpose of which is precision (anticipating that, in the future, I will not be the only user). Don't be a snot! :
  5. Shifted option to select values from field, however here's the problem: The list in question includes company names, of which it is imperative that the spelling be precise. I entered one company name improperly to test whether selecting fields would give me the results I need. When I shifted to use values from the field I found the value list to include the improperly spelled name in it. This is why I initially set the field up to draw data using custom values (whereas all references to company names would be precise). This is important. Because the chance that I'm a blundering idiot (because I'm so green) is high, I ask for your patience (blushing). Thank you for any further feedback or suggestions. Scottish
  6. I appreciate that you included an attachment to illustrate your point, which I will experiment with on a smaller database that I just developed. Seems I might've, could'a, should'a set it up differently. Grrr! It's so frustrating being green. Will letcha know how it progresses...soon. Thanks so much! Scottish[color:green][color:green]
  7. 'ello Enthusiast and thank you for taking time to reply to my post. I don't believe I'm clear on your distinction between using the value list from a field versus a custom-defined list. By using a value list from a field do I understand you correctly to mean to set the field up to auto enter (using value from the last record entered)? My intention for setting it up the way I had...using a custom-defined list...was for precision. Although the database is still in its "infancy" stage at this point, I anticipate that precision would be critical as the database grows [shall I say "grows up,"] and therefore becomes more complex). : Thank you! I'm Interested in your further thoughts and suggestions. Scottish
  8. Greetings! One of my value lists is supplying me with the following message when I attempt to make a new entry: "The length of the selected text (the application automatically highlights the entire list) cannot exceed 30000 characters;" consequently, I'm stumped. Has anyone else experienced this? Is this a global parameter for all value lists (If so, it appears to me to be restrictive for a database program). Presuming I understand what happened here, is there some way to format the list to confirm and/or expand its parameters? Regards, Scottish
  9. Please excuse me. I spoke too soon. The problem appears to be unique to the first line.
  10. Reviewing the problem further, I discovered that (curiously) the problem is unique to my forms of address field (Mr., Ms., Dr. etc.)
  11. Merry Christmas! Sure could use some advice/suggestions for an unexpected problem I'm experiencing getting merge field boundaries to behave appropriately on my printouts. Presently, there is an blank space occurring where no data occurs in a merge field. I want text to automatically shift left (and/or up) when data does not occur in the preceeding field. This is how I've formatted the merge field objects so far to remove the blank space from my printed document: 1. Confirmed that table fields are formatted appropriately (i.e., no extra spaces), and 2. Confirmed that merge fields are formatted appropriately (i.e., without extra spaces), and 3. Formatted merge field object text to align LEFT and UP, and 4. Set sliding/printing to slide LEFT and UP. All this and I'm STILL looking at a blank space on my printout. Thank you in advance for your feedback/suggestions! Scottish
  12. Good afternoon Phil (observing the time difference) and thank you (again) for your reply. Please forgive me as I lost my way out of my private reply to your private message (grrr!), so you get another "public" reply this time (still getting familiar with the features). In response to yours... Indeed I like the concept of portals. Thank you for clarifying their functionality (confirming that calculation fields CANNOT be placed within the portals themselves). I will adjust my report accordingly. Calculation fields apparently CAN be placed on the report where the portal exists and CAN calculate data contained within the portals. See FMP 8's expense report configuration, the same template I adapted for my mailing summary report. I like this configuration; which I believe would, in fact, be ideal for my mailing summary; as well as other reports that I intend to develop as well. So I insist upon using it (smirk). Thank you so much again for your reply. Will keep you posted.
  13. I'm now getting some data, but it does not agree with the data from the source file. Can I start crying NOW?!
  14. Greetings Inky Phil and thank you for your reply. Sorry you weren't able to open the GIFs as I believed the visuals would be helpful to you. Absent of visuals, I will attempt to supply you with the a good verbal illustration of the steps that I took to develop the database and summary report (so far): I developed our primary data source (MAILING CAMPAIGN) from an existing template ("Email Campaign Management") in FMPs BUSINESS - PEOPLE & ASSETS component. This file is being used as our primary data (and data entry) source. The summary report (MAILING SUMMARY) was adapted using an existing template ("Expense Report"), which I borrowed from FMPs BUSINESS - FINANCE component. On the MAILING SUMMARY report, I want to import (via portals) summaries as follows: 1. Calculated totals of all mailings of a particular type (email, snail) and corresponding follow ups of a particular type (email, snail, phone, in person) OR 2. Calculated totals of specific (date or company) mailings of a particular type (emails, snails) and corresponding follow ups of a particular type (emails, snails, phone, in person); and (as well) offering a detail report (of follow ups remaining). Forgive me as well for stating (or over stating) the obvious as well. By "child" file, do you mean the MAILING SUMMARY? Would it therefore be same to assume that the "parent" file is the corresponding MAILING CAMPAIGN (primary data source). I read something on the "parent" "child" references, but they seemed to be applicable to the Japanese language/user (?) so disregarded them. Because it was my intention to use the portal to import data (summaries), I do not have any "new records" in this file and did not intend to produce them, except in the event that we wanted to save a particular summary. The chances that I'm just'a blundering at this point are high. I appreciate your patience. No, I haven't an ounce of Scottish in me (I'm German and Swede). My boss (who has connections and affection for that region) adopted a Scottish terrior on the same day I registered. You do the math : (Seemed appropriate). Are you REALLY a loose cannon? Scottish
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.