This may be of use to you.
I was struggling with something similar (triggering conditional formatting) and Darren Terry posted this over at FMExperts on 23 Jan 2015 in the thread "FMP 13 - Conditional Formatting Conundrum".
"The Commit Records/Requests script step commits all currently locked records in the user’s transaction. So, for instance, suppose you create a new record and don’t commit it. Then, while that uncommitted record is still saved, you start adding related records to a portal (where the relationship allows creation of related records). All of those child records will likewise remain uncommitted until you commit the parent record. If you issue a Commit Records/Requests script step, then all of those records will be committed at the same time.
But you’re absolutely right in that, in the context of a list view in a found set, the Commit Records/Requests script step would only affect the currently active record in the list."
"setting a variable doesn’t lock a record, and neither does navigating to the record. So the Commit Records/Requests script step (in your example) would have no effect. You want Refresh Window instead. You can also use a Refresh Object script step (if you named the formatted text field), but Refresh Window on a list view would be far more efficient."
"If I have seen further it is only by standing on the shoulders of giants." ~Issac Newton
"Commit" is about making sure the data on disk matches the data on your screen. Refresh is about making sure the data on your screen matches the data on the disk. They complement one another. In a standalone solution, they often achieve the same result, as a commit to local data will often trigger a refresh, and vice-versa. It gets a little more interesting when you have a server and multiple users.
You'll want to use Commit when FileMaker would otherwise hold off on saving your changes. For example, if your script changes a field more than once, only the last change might ultimately get saved to disk. If your script depends on each change being written to disk immediately, like when you're using a Magic Key technique or something, then you'll need to Commit after every change to be sure your relationships get updated correctly. Otherwise, FileMaker will sort of wait until it seems like you're finished fiddling with things before it saves anything to disk, which minimizes disk activity and improves responsiveness in normal operation, but it could cause some unexpected results in your application.
On the flip side, Refresh Window will prod FileMaker into checking for updated data on disk that it might not know about, or new variable values that might have changed. If several people are making changes to records from different layouts, your layout might not show the latest data if it doesn't know it has been changed. FileMaker will refresh the layout eventually, but again, it kind of waits until things seem to have settled down before redrawing the window, since doing that requires resources and can be time-consuming. If you need to be sure your window reflects every change as soon as it's committed, you'll need to Refresh manually. An example I was just working on used a timer indicator in a countdown script. Because FileMaker was optimizing its refreshing and waiting until I was finished changing my countdown variable, my window wouldn't show the seconds remaining. Only by refreshing the window every iteration would it refresh the countdown variable value and show the right number on the layout.
Both options do increase the load on a server, though, and in complicated layouts, can slow things down even on a standalone solution. Generally, you want to leave FileMaker to handle these things on its own. I reach for Commit or Refresh only when I need the data to be current every step of the way. Otherwise, it's typically fine to let it wait.
thanks for your hints. The quoted passage here:
All of those child records will likewise remain uncommitted until you
commit the parent record. If you issue a Commit Records/Requests
script step, then all of those records will be committed at the same time.
is, as I understand it, a hint how "transactions" can be achieved...
Roll back because of not committing the parent record ...
Am 29.01.15 um 18:54 schrieb johnnyb:
Generally, you want to leave FileMaker to handle these things on its own.
let me say the following: I would not had even bothered about "how to
make sure that the data is in place or the window shows the actual
state" id I would not have seen layuts in my solution that show massive
lacks on that.
Especially in a layout where I have (here: three) portals I often do not
see what a script has just set. If I do not have a commit or refresh
script step in place... I am still investigating whether just committing
is needed (after I changed something I want to see now) or refreshing
does the job (as sometimes just a commit is not doing the job.
To be honest I am sure that this hints to a lack of understanding of my
TO-portals-scripts-environment... I mean I know what I use for what -
but maybe I do not think it enough trough what is reaching what in a
certain portal-subportal or -sister-portal situation...
You might have two things interacting. Perhaps you need to commit one record so that the relationships can update, and then refresh the window to get the new information from the relationships. It's not impossible!
No, no, it is possible - but I do want (to understand how) to achieve it
with the lowest impact on data transers..
Am 29.01.15 um 20:21 schrieb johnnyb:
Commit Records/Requests vs. Refresh Window ...
Antwort von johnnyb
in /Discussions/ - Komplette Diskussion anzeigen
As Stephen mentioned, a lot of work in this area has been done by Darren Terry. His excellent presentation "Shaking the Dependency Tree" has been given at both DevCon and Pause On Error. Here are some links for your review:
From Darren's presentation:
"Record commit tells FileMaker to update the client that a record has changed, but not, by itself, to refresh the window. If any part of a related record is on the layout, and displayed (including a portal referencing that table with no fields in it), and the value of any field in it changes, then this triggers an automatic window refresh when an unstored calculation depends on its value. This is true even if the field / portal is off the visible area of the layout, or hidden using a tab panel, slide control, popover, or Hide Object."
However, if nothing causes FileMaker to need to make a change (e.g., no unstored calculations that depend on the value in the related field), and another user makes a change to that related record (including the current user making a change in a different window), then the change will not be reflected until the window (or object) is refreshed. So if I make a change to a record and there's nothing causing another user to need that information right now, then he won't see the change until he refreshes.
In terms of what's more "expensive", Refresh Window is considerably more expensive than Refresh Object.
As johnnyb mentioned, the purpose of a Commit is to send the data the client has in the local cache to the server and save it to disk. Until this happens, no other user will be aware of the changes, and the record is locked against edit by any other user. If your script is editing data and you are not running a transactional model (where you want to leave the changes open in case the user needs to revert), then you should commit the changes when the script is done - regardless of your need to refresh the screen. Otherwise, your script leaves the records in an open state and the user has control over whether or not what your script did should actually take effect.
In other words, this question is deeper than just, "What can I do to make my changes show up on screen?" It has to do with proper data integrity and multi-user stability.
It would likely prove more useful if you would give us a more concrete example where you are not seeing the portal refresh when you think it should (perhaps posting a copy of your script) so we can determine exactly what's going on. Hypothetical scenarios are somewhat hard to lock down.
Transactions are not simple and consideration should be given to the context.
One amusing example showed how to remove all of the records in a transaction if say an item was not shown as in stock. I asked why would you want to cancel the customers invoice standing at the register with the item in the grocery cart? For an error in stock control or an receiving ticket not yet posted. Sorry, can't sell you that because it isn't in our inventory. No, well then how about giving it to me for free?
FileMaker is not really designed to do transactions. 4th Dimension is. You can place your order and put holds on items so no one else can see or use that count. Then you issue the commit transaction. You can add or delete as you go. Two simple functions: start transaction and commit transaction.
Commit and Refresh Window are not enough.
You must make sure that what is in memory is written to disk and to the server and then into the memory of the other clients.
Database applications can hold large amounts of 'committed' or 'saved' data in memory BEFORE writing it to the drive. Pull the plug and lose all of that. Drop your connection and the server is not aware of it nor is your computer informed of any changes.
Please correct me if I am wrong but I believe Flush Buffer is the only step that FORCES a saving of data in memory to the drive and to the server.
It's frightening to realize how fragile the database data is say there are 20 data entry clerks entering data like mad. Their FileMaker is set to flush only every 10 minutes. So at 9:59 200 minutes of data entry are still at risk just before the total black out at 9:59:59. They were working on my paycheck...
I've only used one database that would not loose an enormous amount of work if the power failed, Foxbase. (or xBase). They were created when memory was scan and disk space minimal (no virtual memory). And so they saved almost every keystroke to disk as it was made or at least every field when you tabbed out.
My belief, correct me if I am wrong, is that no modern database saves the data entry immediately to the user's drive for safe keeping but instead nurtures in in RAM where it is volatile. 4th Dimension I am told had a keystroke saver so that in case of a crash it could rewrite all of the data entered after the last save.
Interesting - I read an article of Todd Geist
have a look
who emphasized that Transactions are available since quite a time.
He explained how to achieve them. As I remember it it was that the
data that should go in one transaction has to be in a portal (or
more portals) and till the main-recordset is not saved all new
portal rows are also not.
But I have to admit that I thought while reading that a while ago:
how complicated (Filemaker seems to have implemented the
how hidden (as I have not read much about that before anywhere else).
Well, what is it - a technique to implement transaction-like
functionality or really Filemakers intention to make Transactions available?
Am 30.01.15 um 04:14 schrieb jackrodgers:
Commit Records/Requests vs. Refresh Window ...
Antwort von jackrodgers
in /Discussions/ - Komplette Diskussion anzeigen
Transactions are not simple [...]
FileMaker is not really designed to do transactions.
Don't agree. As Luna indicated. The FM steps to code a transaction approach are simple, very well documented and have been around for close to a decade now. And it all revolves around native FM behaviour.
The business logic around when to start and stop a transaction may not be simple but that is something else.
Recently, I implemented an perform script on server setup that updated the order of data in a portal. Without going into the details to much. The Perform script on server ran much faster then running the script locally. Once the script was complete, I used refresh to make sure that the user saw the current/correct record set and order.
I find that doing complex manipulation of data is often best done off screen. When this is done and the process is complete, refresh or refresh with flush cashed join results, displays the new version of the data to the user.
I think you are getting overly concerned about this. Commit writes the data to the database. Here is the information from the Help:
Committing data in records
Unlike most word processing applications, FileMaker Pro saves your data as you work. This is called committing data. Data is committed when you:
select another record
click anywhere outside of the current field
Windows: Press Enter on the numeric keypad, or Ctrl+Enter on computers without a numeric keypad
OS X: Press Enter (not Return), or Fn-Return on computers without a numeric keypad
switch to another mode
If you enter data incorrectly in a record, you can restore the original data to the record as long as the information is not committed. For more information, see Restoring data in records.
When you change related data (such as related records displayed in a portal), these changes are not committed until you commit the record that is displaying the related data.
In FileMaker Pro 10, there was a change to how FileMaker Pro performs the Replace Field Contents and Relookup Field Contents commands and script steps. Replace/relookup operations are now performed without committing the active record. This change only affects multiple uncommitted records in a window transaction, as when you do a replace/relookup on related records in a portal. If there are uncommitted records in the window that are affected by the operation, these changes will be made using the window's transaction and remain uncommitted until you choose to commit the changes following the completion of the operation. All other records will be modified and committed during the operation as before.
Your understanding of "flush cache" (not "flush buffer"; there is no such option) is faulty. From the Help for the Refresh Window script step:
"Select Flush cached join results to delete the results of queries for related records and cause related records to be refreshed. Do not select this option if you know your script does not affect related data, and if you want to minimize the performance impact of re-accessing related data (particularly when sharing a database over a network)."
The every-10-minute refresh you refer to has nothing to do with sending data to the server. It has to do with refreshing each client with the latest data from the server.
As Bruce has pointed out, Commit does in fact send all pending edits for the current transaction (the current record and any related edits) to the server to be saved.