Hello @John Mark Osborne Sorry for the delay in this reply and thanks for your comment! Yes, I believe transactions is another way to combat record locking. For example, if you attempt a transaction that includes updating one thousand records but one of them is locked, the transaction will automatically "revert" thereby not allowing any of the records to be edited. In some cases, this is the desired result. However, in other cases, you may want something to edit all the records it can and then later go back and run the routine again for the records it didn't get to on the first pass. If this is the case, you might be better to build the script without using the new transaction script steps. *More thoughts:* Using transactions is an "all or nothing" scenario that developers have been asking for for years, yet at the same time, I'd caution developers to consider the big picture on what they expect from a given script. Yes, there are times when we want an "all or nothing scenario" (like updating inventory perhaps). But then there are times when we don't want an all or nothing scenario (like flagging all records that are technically complete on their own as an individual records with no dependency on another record). For example, if we have a script to flag all records in a given zip code range. Just because one record is locked, doesn't mean we don't want to flag all the records we can. In addition, and as a general rule, transactions only work under "ideal conditions" so their ability to succeed will be lower than a traditional script that doesn't use transactions - such as the case of updating a mass group of records. So, using my example of flagging all records in a given zip code range for a minute, assume that a developer incorporates transactions with that script and also assume that the database is very busy with at least one user in the group typically editing a record at any one time. A routine to update zip codes using transaction script steps many rarely succeed simply because 9 times out of 10, someone happens to be editing one record in the found set you are trying to update. Something to think about!! 🤔
Hello @Gabriel Gomori Interesting idea! My guess would be the closest thing to that would be the up-and-coming "Custom connections" that Claris Connect is going to allow in the near future. That will enable us to tap into third-party APIs and build a connector for it directly in Claris Connect. And because Claris Connect has built-in webhooks already, this can address the receiving part of the message. I'm not sure we'd ever see something completely "native" but when they open up the doors to Claris Connect, we should start to see some rapid innovation from the community.
@@ProductiveComputing I have my own solution using an android phone and a couple Android apps to execute relaying messages from Filemaker to send and to Filemaker as texts are received. But since both Filemaker and the Mac are Apple products, why would we not have this working natively via an iphone as the sender / receiver? My solution will not work beyond Android 8, so now I am using old Galaxy S7s to make this work. So this will not work forever. Next option is using Twillio's API, but once again, why wouldn't Apple make this happen?
@Gabriel Gomori It could be a matter of resources and priorities perhaps. Twilio is a good solution and we've done a two-way text send/receive for some clients here already, so your idea on that is a good one. As a general rule, Claris likes to incorporate technology that will work for both operating systems (not just a single OS). Of course, this rule is broken on the Claris side with Linux being the only OS able to run Claris Server at the moment. Now that I say all this, they did also adopt some Apple-Only tech by way of the "Get Live Text" function and the machine learning stuff they've recently added. True, all of that was Apple only, but it may have also been very low-hanging fruit by comparison to what it takes to pull off a two-way integrated text messaging connection. (The scope of Live Text and ML is limited to a single function or two so it may have been much easier to get out the door). To incorporate a native two-way text solution with Apple Messages would be a much, much larger integration with lots of features and options needing to be baked in for it to be valuable for developers to adopt. I can also envision a robust UI to manage all that. But I get what you are saying here; it's Apple after all, so why not start with their own stuff!? If we're going down the road of "Apple," why not adopt a fully integrated Mac Calendar, Mac Notes, and potentially even Mac Mail with FileMaker? So, I'll go back to my opening statement which is to say It just could be that they had to draw the line somewhere, and these ideas/features don't make the cut as helpful as many of them would be. All eyes are on the new Claris platform and that's where the majority of the news is headlining today. The good part of this is that Claris Pro and FileMaker share the same base code and it seems that they first release features to FileMaker Pro, then later to Claris Pro (at least that's what the current track record is showing). 2023 will be a telling year for all of this...
Another great video… seems to me the new transaction features could be used to combat record locking?
Hello @John Mark Osborne Sorry for the delay in this reply and thanks for your comment! Yes, I believe transactions is another way to combat record locking. For example, if you attempt a transaction that includes updating one thousand records but one of them is locked, the transaction will automatically "revert" thereby not allowing any of the records to be edited. In some cases, this is the desired result. However, in other cases, you may want something to edit all the records it can and then later go back and run the routine again for the records it didn't get to on the first pass. If this is the case, you might be better to build the script without using the new transaction script steps.
*More thoughts:*
Using transactions is an "all or nothing" scenario that developers have been asking for for years, yet at the same time, I'd caution developers to consider the big picture on what they expect from a given script. Yes, there are times when we want an "all or nothing scenario" (like updating inventory perhaps). But then there are times when we don't want an all or nothing scenario (like flagging all records that are technically complete on their own as an individual records with no dependency on another record). For example, if we have a script to flag all records in a given zip code range. Just because one record is locked, doesn't mean we don't want to flag all the records we can.
In addition, and as a general rule, transactions only work under "ideal conditions" so their ability to succeed will be lower than a traditional script that doesn't use transactions - such as the case of updating a mass group of records. So, using my example of flagging all records in a given zip code range for a minute, assume that a developer incorporates transactions with that script and also assume that the database is very busy with at least one user in the group typically editing a record at any one time. A routine to update zip codes using transaction script steps many rarely succeed simply because 9 times out of 10, someone happens to be editing one record in the found set you are trying to update. Something to think about!! 🤔
when will Filemaker natively connect with Apple Messenger - to be able to send and receive texts from within Filemaker?
Hello @Gabriel Gomori Interesting idea! My guess would be the closest thing to that would be the up-and-coming "Custom connections" that Claris Connect is going to allow in the near future. That will enable us to tap into third-party APIs and build a connector for it directly in Claris Connect. And because Claris Connect has built-in webhooks already, this can address the receiving part of the message. I'm not sure we'd ever see something completely "native" but when they open up the doors to Claris Connect, we should start to see some rapid innovation from the community.
@@ProductiveComputing I have my own solution using an android phone and a couple Android apps to execute relaying messages from Filemaker to send and to Filemaker as texts are received. But since both Filemaker and the Mac are Apple products, why would we not have this working natively via an iphone as the sender / receiver? My solution will not work beyond Android 8, so now I am using old Galaxy S7s to make this work. So this will not work forever. Next option is using Twillio's API, but once again, why wouldn't Apple make this happen?
@Gabriel Gomori It could be a matter of resources and priorities perhaps. Twilio is a good solution and we've done a two-way text send/receive for some clients here already, so your idea on that is a good one.
As a general rule, Claris likes to incorporate technology that will work for both operating systems (not just a single OS). Of course, this rule is broken on the Claris side with Linux being the only OS able to run Claris Server at the moment.
Now that I say all this, they did also adopt some Apple-Only tech by way of the "Get Live Text" function and the machine learning stuff they've recently added. True, all of that was Apple only, but it may have also been very low-hanging fruit by comparison to what it takes to pull off a two-way integrated text messaging connection. (The scope of Live Text and ML is limited to a single function or two so it may have been much easier to get out the door). To incorporate a native two-way text solution with Apple Messages would be a much, much larger integration with lots of features and options needing to be baked in for it to be valuable for developers to adopt. I can also envision a robust UI to manage all that. But I get what you are saying here; it's Apple after all, so why not start with their own stuff!?
If we're going down the road of "Apple," why not adopt a fully integrated Mac Calendar, Mac Notes, and potentially even Mac Mail with FileMaker? So, I'll go back to my opening statement which is to say It just could be that they had to draw the line somewhere, and these ideas/features don't make the cut as helpful as many of them would be.
All eyes are on the new Claris platform and that's where the majority of the news is headlining today. The good part of this is that Claris Pro and FileMaker share the same base code and it seems that they first release features to FileMaker Pro, then later to Claris Pro (at least that's what the current track record is showing).
2023 will be a telling year for all of this...