David Jondreau

Members
  • Content count

    2,064
  • Joined

  • Last visited

Community Reputation

74 Excellent

1 Follower

About David Jondreau

  • Rank
    Huzzah!

Profile Information

  • Gender Male

Contact Methods

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

FIleMaker Profile

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

Recent Profile Visitors

13,559 profile views
  1. Store for Solutions

    Steve (or anyone), Wasn't there a place for developers to sell solutions on FM Forums? Like an App Store for FileMaker? Is that still around?
  2. Losing clients to "Podio"

    Focus on a different market. Hire a sales person. Switch to being a Podio developer.
  3. Losing data

    Sounds like a serious problem. And frustrating! It's unlikely upgrading from 12 to 13 would cause data loss. And it is difficult to help with such a vague problem. Are you hosting using FileMaker Server? How is the database being hosted (3rd party, in house)? What are the specs on the hosting machine? Who is responsible for ensuring there is access to it? Are Go users doing data entry locally, then syncing or are they using the server live? Is all data missing or just some? If just some, is it certain users or certain times of the day? If you drop FileMaker, what is your plan for transferring data and ensuring that the new system works? What if when the new system doesn't meet expectations? There are probably 30 questions like these a FileMaker consultant will ask you, and the questions will depend on answers to previous ones and many of the questions will come up based on actually reviewing the database itself. Doing that sort of back and forth asynchronously on a forum isn't a good use of time. In Columbus, I recommend Joe Simpson: http://radicalappdev.com/contact-2/  
  4. 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?    
  5. 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 )
  6. Dynamically change font size based on length of data

    The function TextSize() combined with Length() as an auto enter calculation could work...
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.  
  12. 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.
  13. 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.
  14. 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.
  15. 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).