Search the Community
Showing results for tags 'commit'.
Found 3 results
In this article the term "self-aware window" refers to a FileMaker window that can know in real-time whether or not it is the currently selected window, and act accordingly. We introduce a technique for allowing individual windows to calculate this, and some examples of what windows could do with that knowledge. Read the Full Article Here…
Hi friends - Back here again after many years to ask some of your first-class advice please.... I have a very old solution which I recently converted from fp7 (can't even remember which version I originally created it on) to FM12 and am checking performance. Windows Vista on a trusty old Dell laptop. There is a script triggered by a button, which pauses indefinitely for user input. Many moons ago, the script would resume when the user pressed Enter on the keyboard. Now, it will only resume if the user either 1) clicks on 'continue' in the status toolbar, or 2) presses Ctrl + Enter 3) clicks out of the field, then presses Enter So if I have the button on a layout which does not show the status toolbar, the only option I can see to get the script to continue is to train the user in method (2) or (3), both of which are clunky and not really what you would expect to have to do. I can see users clicking anything and everything in frustration.... What happened to plain old 'Enter'? This is from the FM help file: "Select 'Indefinitely' to pause the script until the user clicks Continue (a button created by FileMaker Pro in the status toolbar) or presses Enter" Hmm......sorry, but just 'Enter' doesn't work. I'm guessing that this is because the data the user inputs needs to be committed before the script will continue. So the user has to click out of the field to commit the data and then Enter to continue the script. Is there any way to neaten this up please?
I'm having an issue with and offline sync setup that I created. I used the basic outline as described in the FM white paper for offline syncing. I'm using a transactional model for the whole sync process, so there is a final commit at the end if things don't throw an error. It is this final commit that is currently giving me problems. When this commit fires, all of the records that were created during the sync process are once again tagged as being 'modified', and so the modification timestamps are updating again. Here's an example: say I sync 3 records at 22:43. During the sync process the modification time stamps for these 3 new records, reflected at the destination, are: 1: 15:00 2: 13:24 3: 18:31 That's as it should be. But then at the end of the process, when the final commit happens, the three records change: 1: 18:31 2: 18:31 3: 18:31This sync process has a modification override feature, such that when a record is recreated at the destination it will still show the modification TS from when it was created/edited at the source, not when it was copied to the destination (the server). The FM white paper does this with a 'modification_TS' override field. So I have two mod_TS fields: 1 is a standard 'last record modification TS' called "zModTS_Always", and the other is "ModTS_Useful" field that is supposed to reflect the timestamp the record was modified by the user, and not the one where it was modified by the sync process. This override field is used only during the sync process. It is defined thusly: If( zModTS_Always and Sync::ModOverride_g ; Sync::ModOverride_g ; zModTS_Always ) This is important because you don't want the modification time to be changing whenever someone syncs - this would cause all kinds of re-syncing between users. My problem is that the final commit at the end of the sync process is causing all the records that were just created at the destination to have their 'Useful' timestamp updated one last time, and set equal to the 'useful' time stamp of the last record sync'ed. It isn't the timestamp at the point of the sync itself, the override field is still functioning as expected, it is just being fired for records that are not the current record. This might not be too much of a problem...at least the times are something prior to the sync time. But I am sorting a portal of these records based on this timestamp, and having them all with the same timestamp makes the sort rather useless. Or if I were to commit each record after it was created, that would probably solve the problem - but that eliminates the transactional benefits. So I'm just not certain what is causing all these records to be modified one final time when the commit is done. Anyone familiar with maintaining modification timestamps using a transactional technique? Thanks, Justin PS. Lee, sorry if this is in the wrong place; I didn't see any other sub-forums anymore, just the 14/13/Older general discussions.