• Content count

  • Joined

  • Last visited

  • Days Won


LaRetta last won the day on January 11

LaRetta had the most liked content!

Community Reputation

463 Excellent


About LaRetta

  • Rank
    Lifelong FM Student

Profile Information

  • Gender
    Not Telling
  • Location

FIleMaker Profile

  • FM Application
    15 Advanced
  • Platform
    Mac OS X El Capitan
  • Skill Level
  • Membership
  • Title
  • Industry
  1. I wouldn't mark the records if you can help it. You will end up with only those records so why mark them anyway? Do you have another reason to wanting them marked?
  2. I see no need to tag the records. What you want is a found set of only the records you want to import into, correct? The first set of numbers is the record number which is used to isolate the records and the second is the serial which happens to be same as record number but doesn't matter at all.
  3. I had just finished an example. See if this gets you closer to what you want. It appears this is similar to Comment's suggestion. Select#numRecords.fmp12
  4. Gilbert13, Comment asked a question and you never answered him. If you don't answer our questions, we will be unable to help you properly. :-) As a matter of fact, you never responded to Lee either. You are telling us what you want but not WHY. What is the reason you want this? Now you have two questions.
  5. This is cool, Michael, thanks for sharing it!
  6. 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.
  7. 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. :-)
  8. 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: 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.
  9. 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! :-)
  10. 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. ;-)
  11. 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.
  12. 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.
  13. 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! :-)
  14. 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. :-)