After I got home I recorded my entire session from this year’s DevCon. Here it is along with all the files that I used in the session. Hope you enjoy.The video player below should allow you to play the video in HD and in full screen. Click “HD” for HD and the little monitor icon to go Full Screen.

Apologies, unfortunately the demo files have gone missing.

After I got home I recorded my entire session from this year's DevCon. Here it is along with all the files that I used in the session. Hope you enjoy.The video player below should allow you to play the video in HD and in full screen. Click "HD" for HD and the little monitor icon to go Full Screen. A

27 responses to “Understanding Commit Record Video”

  1. Milan says:

    Thank you Todd, this is just what i was looking for, so simple, yet so usefull.

  2. Lee Smith says:

    Hi Todd

    Excellent presentation. Thanks for sharing your Devcon presentation with those of us who couldn’t make it.

    Lee

  3. Marek says:

    Hi Todd,

    How could I download the files used in video as you mentioned at video description above?

    Marek

  4. Brian says:

    I’ve looked at the video and also at you demo files. really enlightening, thank you. Does the commit record step work if the related table is in an different database hosted on the same server rather than in the same database as in your demo files?

    Thanks

  5. Alfonso says:

    Hi!

    Very nice presentation, one of the best ones I could attend to at devcon last year.

    I have a question about how this works with field validation. Using your file, I marked the field “Date” of the expenses table as required. Doing so will prevent de record from being committed until I insert a date. Unfortunately, no error message is shown, no FM Dialog popping up. The most I could do was trap error number 509 and show an error dialog with a simple message like “Something is wrong” (since I don´t know if it´s possible to know which field was wrong and get its corresponding error message). How would you deal with field validation? Do I have to manually validate the fields inside a script?

    Thanks!!

  6. Dan Smith says:

    Thanks for the video and demo files; they were very clear and informative.

    I noticed that in your “Force Commit Record” script, it exits with Result: Get(LastError), but the “Save…” script(s) that call the “Force Commit Record” script also test for Get(LastError), rather than Get(ScriptResult). I hadn’t realized that Get(LastError) would persist all the way up to the calling script, so it was cool to see that.

    My question: is there a reason you also exit with the last error, since you don’t test for that value in your calling scripts (in this demo, at least)?

    • Todd Geist says:

      Hi Dan,

      Congrats you found a bug :-). What you see in SimpleDemo is wrong! That script step should be Get(ScriptREsult) not Get(lastError). You are the first person to notice. 🙂

      Look at the “Expensed” demo file, and look at the “Save New Expense Report” script you will see that I use Get(ScriptResult) to retrieve the error from Force Commit Record script. That is how I typically do it.

      Sorry for the confusion.

      Thanks for finding that.

      Todd

    • Todd Geist says:

      Thank you! Glad you liked it.

      So yeah Field Validation is an issue. If you have turned on error trapping, no message is shown, as you correctly point out. But you can modify the script to handle field validations if you use them.

      Here is how you can fix it, In the “Force Commit Record” script trap for error 509 right after the commit. Instead of exiting, like the demo, do this:

      Set Error Capture Off
      Commit Record <- this will again trigger the validation, but now that Error Capture is off it will show the Field Validation Set Error Capture On You only need to do this if the error is 509 so wrap the above in the appropriate "IF" That will do it! Thanks Todd

  7. Joseph says:

    Hi Todd,

    I am late to the party. Great presentation. I do have a question. I am using your Expense Report demo

    When creating new Expense Report, the expense splits are entered directly into the portal. This works. But if I use a script to enter the expense split ( which I do most of the time) , it will not shown up in the portal unless I forced a commit. In this case, I will not be able to revert the record but to delete it. Is there a way to make the expense shown up without the force commit ?

    Cheers
    Joseph

    • Todd Geist says:

      Hello,

      If your script is working on the same portal then you it should show up with out a commit. If however your script is going off an entering splits through some other relationship then, no, there is no way to see it with a commit.

      Hope that helps

      Thanks

      Todd

  8. ron says:

    Great presentation!!!!!
    It seems that FM 12 with it’s Window controls would change the Commit requirements. Do you plan on making a video using FM 12?

    • Todd Geist says:

      Hi Ron,

      Thanks!

      The new windowing model in FM 12 doesn’t fundamentally change how commit records works. It still works the same way. Is there something specific about the presentation that you think might be different with FM 12?

      Thanks

      Todd

  9. ron says:

    FM 12 has more Window ‘Styles’: Document, Floating and Dialog. It ‘seems’ like using these styles would at the very least, prevent the focus from going to the main window…. Anyway, for what it’s worth I would be nice to have these ‘styles’ and their affects brought into your excellent Commit video.

    On the other hand, I can screw around with it and try and figure it out…. 8)

    • Todd Geist says:

      Hi Ron,

      Although we didn’t have a specific Modal window type until 12, we were able to get the same modal behavior using a loop pause. The new Modal window style certainly makes it easier to achieve but it doesn’t really change what we could or could not do with regards to committing records. If I make a new video, perhaps I can just point out that the new window styles don’t really effect commit record behavior. 🙂

      If you do come across anything that you think is different please let me know. I’d be happy to take a look.

      Thanks again for commenting

      Todd

  10. ron says:

    Hey Todd,
    Here is the crux of my problem. I have a script that opens a ‘new’ window which contains the fields in the main window portal. I then loop through each record in the ‘new’ layout running a script on each record. This works.

    The weirdness is that after the script loops through about 20 records (I can watch it in debug), I get the dreaded “This record can not be modified because it is being modified in another window” message.

    Question: “Why after 20 records”? Should this condition be evident from record 1?
    Loop
    Go to field (Dues::Date)
    Perform Script “Reset Dues PaidYear”
    Goto Record / Request/ Page (Exit after last)
    End Loop

    I even put a ‘commit’ before or aftere the Perform Script and it did not help.

    Ideas?

    Thanks

  11. Dan Smith says:

    I just used this method to create 5000 records in a single commit (in a local file) and it took ~180 seconds. Surprised by the performance hit, I added a commit step to my script after every 50 records, then it only took ~40 seconds. After playing around with a few things, it seemed like one/all of: field validation, auto-enter calcs, field indexing was causing the script to take as long as it did to commit the records.

    Have you seen similar performance issues using this method? Are there any tricks to improve performance?

    Thanks,
    Dan

    • Todd Geist says:

      Hi Dan,

      Usually single commits are faster, at least up to the point of the filling up the local memory, which can happen on FM Go. The difference is usually amplified when committing over the LAN.

      BUT there are times when it is slower. And often that is because of the nature of the auto-enter calcs, and field validations that are in use. For example if you have a field validation set to unique ( which I almost never do, for this reason ), it will get very slow when using single commits. This is because the field validation still has to examine all those records that are NOT committed and indexed yet to look for duplicates. So calcs that have to look at many records are going to cause slow downs.

      Hope that helps

      Todd

  12. Steve Kemp says:

    Hi Todd,

    Have you any experience with using the transactions approach with multiple files (e.g. interface file/data separation or FileMaker Go file on the device syncing to hosted FileMaker Server file)? I’ve noticed that there are certain circumstances where I need to add a commit records step immediately after creating the new record, otherwise I will end up with 2 records once I set additional fields after first creating the record.

    Just wondering if you had encountered this before? It seems to prevent the use of the transactions technique in this scenario as you have to commit the record to prevent duplicate records being created, so you can’t revert at a later stage.

    thanks,
    Steve

    • Todd Geist says:

      Hi Steve,

      Yes we use this with file/data separation and with FileMaker Go syncing to a server. In general the technique works well. But there are lots of little silly things you have to watch out for. One that may account for what you are seeing, is that if you

      1. create a new record through a relationship
      2. break the relationship
      3. try restore the relationship to the record you previously created

      it won’t work. The new record is there in memory, and will be committed with everything else, but you have lost access to it and you can’t ever get it back.

      So if you then proceed to edit more field on that record, you’ll likely create another record, because you can’t reach the original one.

      So whenever you create new records make sure you do everything you need to do to the record before letting go of the relationship.

      Hope that helps

      Todd

Leave a Reply