What tables are you talking about?  Most tables have these two fields.  You can read these fields to know if updated.

105  DateUpdated . . . . . . . . .     8 SNN  Last Update Date. . . . . . . .DATE
                                                Read Only:Y Notes: YYYYMMDD
 106  TimeUpdated . . . . . . . . .     8 SNN  Last Update Time. . . . . . . .TIME
                                                Read Only:Y

That's what I do today, but I have to keep reading these fields every minute. Or change the service to read every X seconds, which might be heavy on the database, no?

And here...

Thanks for the resources. I've went through the word document, which is very useful. However, it doesn't discuss the "one Table Post-Write per "Accept"-ance".

Is there any way to solve this programmatically, without closing then re-opening the window?

The window does not need to be closed to trigger subsequent events. These table based event scripts are triggered by table activity and not the user interface. Changes in the panel are written when you click the Accept button. That doesn't close the window. Another order or the same order can be re-selected, changed, and another event will be triggered when the Accept button is used again. If this didn't solve you issue, then I'm not understanding exactly what you are trying to accomplish.

The problem could be your object, not Sage.  Try something other than that function (DebugPrint, MessageBox...) to verify when the Post-Write script is running.

If you are on Advanced / Premium, try running in MAS90 mode to verify if your script is throwing an invisible error (or is otherwise being locked up).

In fact, the issue is somewhere in my objects. But I can't figure out where. See the following trace window:

I updated the same item 3 times in a row without closing the window. I can see that the script has been triggered 3 times. However, the API call is never re-made because my API response is a GUID that should change every time, which is not happening. In addition, my API only logs the reception of requests the first time. It's like my API is never called if the URL is the same (because it gets triggered if I change the item or if I close and then re-open the window).

Here is my updated script:

retVal = oScript.DebugPrint("Script Triggered")

url = ""
itemCode = ""
response = ""

retVal = oBusObj.GetValue("ItemCode$", itemCode)
url = "https://localhost:7017/Synchronization/ping/" & itemCode & ""

retVal = oScript.DebugPrint("URL: " & url)

Set o = CreateObject("MSXML2.XMLHTTP")

o.open "GET", url , False
o.send
response = o.responseText
oScript.DebugPrint("Response: " & response)

Set o = nothing
Set itemCode = nothing
Set url = nothing
Set response = nothing

Moreover, if, instead of sending the item code (which never changes) in the URL, I send the description (which I am updating for the sake of testing), the API call is made successfully because the URL has changed.

Is there a sort of a cache that is used?

I suspect you may be getting an error from your open or send and the "MSXML2.XMLHTTP" object is not updating "responseText".

I doubt it because if I log the response before and after the call, before the call the response text is empty, and after it is not. If I log errors, I don't see anything relevant about the HTTP request. I'll keep trying though.

Did you try to abort, as a possible way to reset the object...?

https://learn.microsoft.com/en-us/previous-versions/windows/desktop/ms760305(v=vs.85)

I just tried that. No luck. I'll keep looking into it. Crazy though.
Thanks for the help and the resources.

Is there a way to refresh the script?

BOI scripts need to be recompiled after changes, and are loaded into memory as the data entry object is opened... (with no way to "refresh" the script in that data entry session).  Eg. recompile the script, and you have to close / re-open the data entry screen to load the updated script.

BOI scripts need to be recompiled after changes, and are loaded into memory as the data entry object is opened... (with no way to "refresh" the script in that data entry session).  Eg. recompile the script, and you have to close / re-open the data entry screen to load the updated script.