LaRetta

Members
  • Content count

    10,787
  • Joined

  • Last visited

  • Days Won

    127

LaRetta last won the day on January 11

LaRetta had the most liked content!

Community Reputation

463 Excellent

5 Followers

About LaRetta

  • Rank
    Lifelong FM Student

Profile Information

  • Gender
    Not Telling
  • Location
    Everywhere

FIleMaker Profile

  • FM Application
    15 Advanced
  • Platform
    Mac OS X El Capitan
  • Skill Level
  • Membership
    TechNet
  • Title
    Developer
  • Industry
    Software
  1. Such a calculation would be stored and thus would not be slow. Then field [A] is a multiline that you need to report on its individual values separately? I suggest you consider using another table.
  2. Hi Monarch, would you explain the purpose of this? Is it so a User can select a time which must be stored in the table? Is it for the developer to provide the User with feedback of some sort? Knowing what you wish to do with this information will help us determine what to provide. :-)
  3. I explained what you need to do to accomplish your request. If you begin working through it and trying my suggestion, you can then post a question if you get stuck. Here is an example file by Comment which shows a basic join relationship between Invoices and Contacts illustrating the structure needed and as I have explained in my prior post: http://fmforums.com/topic/63425-auto-fill-one-field-with-text-from-two-fields/?do=findComment&comment=300150 and download the InvoicesDemo.fp7 file. As for selecting the customer, you can use a value list or a portal for filtering down your customer selection. Once you get the structure in place and understand my prior post, you can decide whether to select customers via a portal instead of using a value list. Usually, we use a portal if the value list will hold more than a few dozen entries. But you will TRULY want to understand how this join relationship is working AND understand how to create value lists so spending some time in the trenches absorbing these principles will be highly beneficial at this point.
  4. Hi Randy, If you happen to place that field on a different layout and DO allow entry to the field or if there is an import then the field is not protected. Layout protections are used only to enhance data-entry and Security should be in force as needed. I mention it more for other readers since I highly suspect you've taken that into account. You've touched a fine point in layout/scripting behavior. Good observation. Yes, one of the differences between a single step ( button press ) versus script step is that a button is User-driven so User layout rules are applied whereas a script overrules User layout constraints. Nice to see you again! :-)
  5. Assuming there will only be one customer on a single work order, what you describe is known as a one-to-many (one Customer AKA 'parent' to many Work Orders AKA 'child'). You only need the fields (other than the ContactID) if you need to preserve their value for history/audit purposes. For example, if you enter the shipping address but later the Customer changes their address, you want the old Work Order to display the Customer's address at the time of the shipment. So, with Invoices, Work Orders, Contracts and such, it many-times makes sense to duplicate the data into your 'child' (Work Orders) table. You place the parent's unique key (CustomerID) in the child's table. Then, from perspective of Work Order, you select the CustomerID in the Work Orders::CustomerID field using an attached value list which is based upon data, left pane is CustomerID, right pane is customer name, all values, and below, display values from second field. Use a popup control. If you use a drop-down control then it will only display the ID after User leaves the field and you will be required to place the Customers::name field next to the ID for display. The relationship will be: Customers::customerID = Work Orders::CustomerID If you need to retain the data, create duplicate fields in Work Order and use either auto-enter or Lookup to have the values in Work Order fill in when you create a new Work Order. If you do not need to insert the data static, you can always simply display the 'parent' values on your child layout. After creating the relationship, simply place the fields from Customers directly onto your Work Orders layout, select a Customer ID from the value list popup and watch your values fill in or appear on your layout from Customers. There are various training videos and sample files around showing how to create a simple 1:n (one-to-many) relationship using IDs. Do not be tempted to use names for these KEY relationships. You want to use a meaningless ID because otherwise, if you change a name and it is used for a relationship, you can break your relationships and broken relationships are never a good thing. ;-)
  6. You can also use Export Field Contents and skip specifying the field. There are a few more ways as well, such as exporting 0 records using same path file name. All similar principle so it's which you like best. I like Export Field Contents; picked up from Comment, I suspect.
  7. I wonder if it wouldn't be easier to create a summary field (maybe called sDeliveryRemaining' which is 'Total of DeliveryRemaining. Then script could check this value as: If [ not sDeliveryRemaining ] ... then do 'the thing' you wish. Sorry for the glitch.
  8. Hi Wayne, to explain a bit more ... not only does copy destroy a User's clipboard contents (usually needlessly, as Comment explains) but paste requires that the field being set exists on the current layout. Down the road, you may remove that field and cause your script to fail, forgetting that it is dependent upon that field. No such issues exist using Set Field[]. And welcome to FMForums! :-)
  9. Hey there, Datalink! In future, you can always post again on your thread, even just typing 'bump' ... which will bump it up into everyone's view again. It is easy, because we all (including you) are busy, for things to just slide by. By keeping everything in a single thread, it helps us in by reading what others have suggested and your other discussions about the issue. :-)
  10. No need to be sorry at all, Chris. :-) These types of discussions ( should ) take place in almost every solution. Usually the discussion involves names, such as when seeing if a Contact already exists before allowing creation of new contact.
  11. So would I! I started to go into details about an advanced search and presenting User with possible matches for selection but I decided to see if Chris wanted to go that route after realizing substantial number of non-matches. But that seemed a separate issue from colorizing a button which would simply show whether the IncidentReport record has found its match without intervention. As usual, you are ( rightfully so ) ahead of me.
  12. Hi Michael, I assumed ( wrong of me, I know ) that the button would simply indicate that a search must take place to try and find the PrePlan match for the Incident Report address. So if the button is red, clicking it would perform an advanced find in PrePlan for the right address.
  13. Odds are, you will have many unmatched records. Data-entry is rarely ever a match particularly on street addresses, as Comment points out.
  14. For valid relationships ( those that match ) then what I said above should work fine which is ... make the button on your IncidentReport layout red then create conditional format on the button with: not IsEmpty ( PrePlan::Address ) ... and specify green for the fill color based upon the understanding that the field PrePlan::Address is the key field in the relationship or is never empty. :-)