David Jondreau

  • Content count

  • Joined

  • Last visited

Community Reputation

73 Excellent

1 Follower

About David Jondreau

  • Rank

Contact Methods

  • Website URL http://www.wingforward.net

Profile Information

  • Gender Male

FIleMaker Profile

  • FM Application 13 Advanced
  • Platform Cross Platform
  • Skill Level Expert
  • Certification 9
  • Membership TechNet
    FileMaker Business Alliance

Recent Profile Visitors

13,315 profile views
  1. Referencing hosted container

    I have a client that has a server full of image files (jpgs, pdfs, tiffs, etc). They have a FM14 database being served on FMS 14 (Windows Server 2012). They are accessing the server from FMP 14 clients on Macs and Windows. They want to link records in a database to the image files. The want to start from a record in their client FMP, open up a dialog that allow them to search the server machine and choose a file that will be linked to that record. Later they want to go to that record and view the file. Storing the files as containers won't work as the files will be edited (but their filepaths and names won't change). And the filepaths and names have a strict naming convention that can't be changed. How would you accomplish this?    
  2. Dynamically change font size based on length of data

    I was bored...here's on way to create the font.size used in the TextSize() function. It'll give you a whole number between the max.size and min.size. field.size represents the number of characters that you want and still have the max.size font. Let( [ field.size = 50 ; max.font = 36 ; min.font = 6 ; text = table::field ; text.length = Max ( Length ( text ) ; 1 ) ; size.diff = max.font - min.font ; adj = ( field.size / text.length ) * max.font ; font.size = Min ( adj ; max.font ) ; font.size = Max ( min.font ; font.size ) ; font.size = Round ( font.size ; 0 ) ]; font.size )
  3. Dynamically change font size based on length of data

    The function TextSize() combined with Length() as an auto enter calculation could work...
  4. Records disappear

    Just one little point...missing UUIDs don't actually determine if the "record" is still there or not, after all, the UUID field can get overwritten! Get (RecordID) helps with that.  I suppose you could use an calculation field to hold the UUID. I've never tried that though.
  5. Records disappear

    Some thoughts... Using privileges is a worthy idea. I always like to ask, "How do you know what you think you know?" How do you know records were actually "deleted"? Could some data have been changed so those records still exist but aren't showing up in a find? Could a user or script have written over the data, so the record you're looking for is actually another record now? Also, why wait months? Do a weekly check. Or even daily. You could, for example, import all that table's records into a new table each week as a "back up". Then the following week, find all the records that had been created as of the week before and do an import into the back up table, matching on the pk, and "add new". All the new records would be ones that had been deleted and you can compare that list to the the admin approved list. I can think of a couple ways to delete a record without triggering a cascade delete. Primarily if the user doesn't have delete privileges on the child, but does on the adult. Also, if you change data used in the relationship, breaking the link, then delete it. Finally, you do have a UUID field, yes? And Created On, Created By, Modified On, and Modified By fields? And I would recommend a Get ( RecordID ) field as well. It could be helpful in identifying the problem.
  6. Best way to store/reference external files

    How about letting the users put the files wherever they want? Give them the option to pick the file in the import step.
  7. Script Running Way Too Long

    It's hard to tell, but it sounds like there are a couple fundamental changes you can make. You should move to having another table. Instead of a script with 200 If/Else If options, create a table with 200 records. On field would be the code, another field would be the reference. Then you build a relationship between the two tables and use an auto-enter calculation to set Field B. It's not entirely clear if Field A contains a single 7 digit number or a series of them (up to 25?). If a series, you should split those up into separate records as well. Also, are you getting 80 Million new records frequently or is this a one time process? You might be able to save a lot of time by using relationships rather than scripts, but 80 million records is a lot to update. In short, this isn't a scripting problem as much as it is a data structure problem. It would be helpful as well to have the actual data rather than samples. It is easier to understand. A sample file would be great.
  8. Go To Related Record Not Working As Expected

    Yes, well the Commit[] is a problem. Once you commit, that portal row now longer has focus so the rest of the script doesn't "know" that's the row you want. You could do the find. That's my general preference over GTRR. But you could simply take the Commit[] out. If you've edited the record (parent or child) and GTRR with a New Window[] that might record locking issues.  
  9. Perform Script on Server

    Add fields that can capture the unstored data in a stored format. Or just use $variables. You'll have your script do PSOS to grab all the calc results and pass that on to the client. Then go to your report layout, do your find and sort, but don't display your performance-killing unstored fields. Instead use the result from the script to populate display globals or variables.
  10. Layout Behavior-Found sets

    Bruce, I'm confident what I said in my first post is accurate but I should clarify, the found set of the TO of the *current layout* stays the same when opening a new window. However all layouts based on other TOs revert. Keep in mind, in terms of maintaining found sets, FileMaker doesn't actually care about the layout, but rather the TO (not base table) of the layout. Here's a 1 minute video of what I'm talking about: https://youtu.be/fES-BcJCizE Steve's experience is a direct result of this behavior.
  11. Layout Behavior-Found sets

    "Takes a found set and transfers it to the first table". What script steps are you using for this action? Regardless, found sets are tied to TOs and windows. Imagine all your layouts have a default found set (I'm not sure if that's all records, but I suspect it's the found set of that layout's TO when you last closed the file locally). So two layouts based on the same TO in the same window will have the same found set. Opening a new window means all the layouts in that window revert back to the original defaults. Manipulating found sets and switching between layouts in that window will keep those sets but won't effect other windows or layouts based on other TOs (even if they're the same base table) I hope that's clear enough.
  12. Evaluate()

    There are other, better ways to sum subgroups of records aside from multiple relationships. If this is for display only, filtered portals and summary fields work very well if the number of total related records isn't large (more than a few hundred).
  13. Quickfind within a popover within a portal

    You've got to script the "quickfind". Popovers are just layout objects that help you manage your layout real estate. They don't have a separate table "context". I'm assuming you have a portal on the popover and *that's* the table you want to search? There's not a simple answer. And your "quickfind" field is a global of some sort? You can 1) Script it so upon exiting the "quickfind field" you can either create a bunch of find requests each with a different "related field" getting the quickfind data 2) Script it so upon exiting the quickfind field, you go to a different table (one the portal is based on), do a Quickfind search there and the Go To related Record back to the original table 3) Set up layout so only the related fields are set to "quickfind" 4) Rethink how to accomplish your goal. Do you need a popover? How about a new window to a layout based on what is your current "portal" table?
  14. Related Records Issue

    It's not an uncommon error. Go to Related Record[] will take you to *all* the related records for the current record. The checkbox option expands this to taking you to *all* the related records for *all* the records. Personally, I think GTRR[] is more trouble than it's worth. If you want to isolate a single related record, your best choice is to pass the unique primary ID of that related record as a parameter through the button. Then take that parameter (using Get ( ScriptParameter ) ) and do a find on your certificate layout to isolate the record. Also, your screenshots are a little confusing. Shouldn't the Certificate layout referenced in your "Email certificate" be based on Join Contacts Events table?
  15. making FM know what tab you're viewing

    Do you have more than one tab control on the layout? There can be many "frontmost" tabs. FileMaker can't know which tab a user is actually looking at! A custom function like this is probably a better choice: https://www.briandunning.com/cf/694