David Jondreau

Members
  • Content count

    2,069
  • 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,834 profile views
  1. Getting the internal script ID

    Keep in mind, more than one script can have the same name. That may cause a problem in getting the script ID using Design functions.
  2. Script/Function for instant screencapture

    This is not a simple request. It is probably possible using AppleScript and some native FileMaker scripting, but I haven't actually done it.
  3. Find in Portal- Problem

    Unfortunately, @ is a special symbol in find mode. Quotes works. Also changing the fields storage settings to Unicode (though then upper and lower case letters will be treated differently). It's a problem.
  4. No more shared hosting after FMP14?

    I thought the same thing while reading the pdf. There is the cost of the license itself, yes. But there's an additional cost of spinning up a new machine (virtual or otherwise) and sysadmining it. I used to be a "FileMaker Commercial Hosting" provider for my development clients. I got out of it though. It was too much hassle. I pushed everyone off onto other, bigger operations. Clients don't want to handle managing their own server, with backups and OS upgrades, blown ethernet cards, etc. So, even if the cost went up $30 a month for their own license of FMS but still on a shared server, I would recommend they do it. Because it's going to be an additional $10-$30 a month on top of that for a machine....If EULA allows, which is unclear. But that would be a $30 waste since there's only a nominal benefit to the client. Maybe there are other options they haven't announced, like a free FMP client and all costs are server connections, or an FMI hosting service!. Who knows. But if FMI makes no other changes to their pricing or business model, and only does this one thing, basically killing shared hosting, then I think that will drive a lot of small-fry operators off of FileMaker. Maybe that's best for FMI and I respect their choice.
  5. 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?
  6. 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/
  7. 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?
  8. 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 )
  9. Dynamically change font size based on length of data

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