Jeff M Posted April 16, 2008 Posted April 16, 2008 Okay, I've been using FileMaker for years...since version 4 in fact. I'm pretty sure, however, that I could be doing things much more efficiently. Let me give you an example: I often have the need to create a related record in a separate table through a script. Here's what I do: 1. Copy the ID of my parent record 2. Go to layout of the child table 3. Make new record 4. Paste into the appropriate ID field to complete the relationship. 5. Commit the record 6. Go to layout of the parent (original layout) Suggestions on a cleaner way of doing this? Can anyone point me to similar basic topics or best practices. I'm getting things done, but I can't help but think it could be much better.
Ocean West Posted April 16, 2008 Posted April 16, 2008 (edited) here is one way... http://www.filemakermagazine.com/videos/super-quick-data-entry.html When you say "copy/paste" i would recommend setting a $variable and use set field. Edited April 16, 2008 by Guest
Jeff M Posted April 16, 2008 Author Posted April 16, 2008 Thanks for your reply. The example you sent appears to be a variation of the portal data entry method. This will be useful in another area of my database. My current issue has to do with script entered data...for example... A user hits a "complete" button and a script is run that creates a related record and inserts the current timestamp. In this situation, the script does all the work, with no user interaction. You mentioned the use of a variable. I've used variables in other applications, such as REALbasic, but never in FileMaker. How do I define them, how do I refer to them? Most importantly, do they store data like a global field?
Fitch Posted April 16, 2008 Posted April 16, 2008 See Set Variable script step and Using variables. There are some differences between variables and global fields. Global fields - can be displayed on layouts - can be used for input in Show Custom Dialog script step - can drive a relationship - can be referenced from other files Unless I need one of those, I'll always use a variable. They don't clutter up your schema, you can create them as needed in your scripts, and when your script ends, they're gone, no extra cleanup required. Global variables are a little different; avoid them unless you have a compelling reason to use one.
Ocean West Posted April 16, 2008 Posted April 16, 2008 You can use the Set Variable Script step and define the variable by declaring either local scoped or globally scoped by indicating single or double $, respectively. $variable is only available for the current running script and does not pass thru to subscript steps. $$variable is global for the current session and file. And is available after declaration in all of FileMaker's calculation engine dialog boxes. Yes variables can store any type of data text/date/time/timestamp/container however they can not be used as a key as in a relationship you will still need a field (global) for that. Another method to instantiate variables is by use of the Let() function by declaring the $ or $$ as part of the variable portion of the let function these variables can be created programatically.
Ugo DI LUCA Posted April 16, 2008 Posted April 16, 2008 Hi Stephen, Except from conditional formating, there's absolutely no need for FM9 for this technique, and I really don't get how this can be told a revolution as this technique exists since FM7. That's what I have always called a Magic Key. In this case, a relation from a global to the primary key of the related table with allow relation of related records checked. Set Field [ global ; "" ] Set Field [ MyRelation_creation::foreinKey ; PrimaryKey ] Commit Record Set Field [ global ; "" ] That's all is needed here
fabriceN Posted April 16, 2008 Posted April 16, 2008 (edited) Ugo, the global can empty itself if you don't need the related ID. This makes your script ways too long : You don't even need a script in fact. Edited April 16, 2008 by Guest
LaRetta Posted April 16, 2008 Posted April 16, 2008 (edited) Of course this only works if there is only the one (current) related record based upon the Primary ID. If there is more than one related, you'll need to pull in another field OR perform the old standby which was suggested, of silently going to the related table to perform your work (or use portal). I like Allow Creation and use it quite often but it isn't ALWAYS the answer. :wink2: Edited April 16, 2008 by Guest
Ugo DI LUCA Posted April 17, 2008 Posted April 17, 2008 Yes Fabrice, no script needed at all, I agree, here and in this video. LaRetta, not sure I'm getting it ?
Recommended Posts
This topic is 6123 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now