Jump to content


Popular Content

Showing content with the highest reputation since 12/04/2010 in all areas

  1. 3 points
    I use 'Hide Object When'. Make two instances of the same field, One is editable, the other not. Give them complementary conditions for hiding and place them on top of each other. The non-enterable field is hidden when the value not = "No". The enterable field is hidden when the value = "No". Easy in FM 13...
  2. 2 points
    Well, yes. The standard way is not to do it at all. The very idea of a relational database is to store data in one place only. The data that describes the parent record would be stored in the parent table only. The data that describes the children would be stored in the child table only. Thee should be no need to copy anything in either direction. An exception to this rule is when child records lookup data from the parent at creation, so that subsequent changes in the parent do not affect the child. A prime example of this is invoice line items looking up the current price from the product catalog. In the (very rare) case of requiring the child records to update the looked-up values from the parent, you can perform a relookup.
  3. 2 points
    Try: Let ( dot2 = Position ( Version ; "." ; 1 ; 2 ) ; Case ( dot2 ; Left ( Version ; dot2 - 1 ) ; Version ) ) -- What the heck, let's have another: Substitute ( LeftWords ( Substitute ( Version ; "." ; ¶ ) ; 2 ) ; ¶ ; "." )
  4. 2 points
    Rather than performing math on just the Month component, use the complete date, then pick it apart again; e.g. … Let ( [ cd = Get ( CurrentDate ) ; fiveAgo = Date ( Month ( cd ) - 5 ; 1 ; Year ( cd ) ) ] ; Month ( fiveAgo ) & "|" & Year ( fiveAgo ) ) returns (today) "12|2013"
  5. 2 points
    The problem is not with OnObjectValidate, but with the way you're trying to use it. The script runs before the field has been validated or saved - therefore no related record exists yet (or, if the field has been modified, the related record is the one that matches the original field value). Try triggering the script OnObjectSave or OnObjectExit. There must be something else you have there. Deleting a record does NOT trigger a script attached to a field.
  6. 2 points
    Hi this is a different approach to the problem. Split Word.zip
  7. 2 points
    Also try: not IsEmpty ( FilterValues ( Portal::property ; Table::LogField ) ) This IsEmpty ( FilterValues ( ... ) ) construction seems to be the de facto standard way to check if a value is in a return-delimited list, but the performance is best when the list you expect to be shorter — such as the one-value Portal::property field, in this case — is the first parameter of the FilterValues function.
  8. 2 points
    OnRecordCommit is your best bet, but beware, it a) won't fire every time a record is left, only when the record is changed (opened) and it will fire every time the record is committed, not just when the record is exited. You can solve a) pretty easily with an OnRecordLoad trigger that uses Open Record[], but is pretty annoying to work around. We could probably help better if you explained what you are trying to accomplish in plain English, not using the mechanics of FileMaker. Like "When a user views a person, that needs to be recorded so their manager can see who is still left to be viewed." Not "A field needs to be changed."
  9. 2 points
    MirrorSync keeps track of which change was made last, and selects that as the winner in a conflict. So if a record is changed at 2PM on one device, and 3PM on another device, the 3PM change will win the conflict. The exception is that changes always win over deletions, regardless of which one happened last. A common misconception is that conflict resolution is based on who syncs first or last - MirrorSync will pick the record that was EDITED last, not the one that was SYNCED last. So for your example, if you and I were both syncing with the server, and I changed the record at 2PM, and immediately synced, and then you changed the record at 3PM and synced, your change would be kept in your version, and I would get your change the next time I sync. If we flip the situation, so you change the record at 2PM, but I change the record at 3PM, then my change would overwrite yours, regardless of whether you synced immediately after making the change or waiting until the following day.
  10. 2 points
    Alright! Developer DUH! Moment. I got a reply from Brent at 360Works. He mentioned it seemed like a permissions issue. Of course, I forgot to walk through the GOLDEN RULES OF DEBUGGING! This is for those of you doing stuff outside of FileMaker. Rule #1 Did you check the log (find it if you don't know where it is) Rule #2 Is it a permissions issue? Rule #3 Go back to Rule #1 and start over! My problem was with a custom function I had which was auto-defining the path. The lesson learned here is for any conversion from .fp7 format to .fmp12 format you need to make sure any instances of .fp7 are converted. I had a function which was Substituting a Get ( FileName ) & ".fp7" off the path. Of course, if .fp7 is not found on a .fmp12 file THEN you may be trying to write to a path where you don't have permissions - such as inside a FileMaker file. DUH!!!!! P.S. Migration tip when moving from .fp7 to .fmp12. Use the Dracoventions Developer Assistant to find all instances of ".fp7".
This leaderboard is set to Los Angeles/GMT-07:00

Important Information

By using this site, you agree to our Terms of Use.