As far as I can tell, the use of Perform Script on Server isn't a requirement to the functionality of the audit log, but is used to increase performance for end users. But for developers, especially during this beta stage, the ability to step through the code would be useful.

 

Perhaps at the top of the main script there can be an override variable that will use local execution instead.

Set Variable [$local_execution; True]

Then each of the calls to Perform Script on Server would be replaced with conditional code like the following:

Set Variable [$parameter; Substitute ( Get ( ScriptParameter ); "Baseline"; "Baseline Server" )]
If [$local_execution]
  Perform Script ["EasyAudit"; Parameter: $parameter]
Else
  Perform Script on Server ["EasyAudit"; Parameter: $parameter]
End If

With the use of the $parameter variable eliminating the need to edit that twice if it later changes.

 

Thanks,

Chuck

Chuck --

 

Actually, PSoS is required for the handling of the "Commit" event. We use PSoS to spawn what can be best described as a listener, which gets spawned when a user starts to commit data, waits for the commit to be reflected in the database, and then logs what it sees. In other words, we use this approach to simulate an OnRecordCommit trigger that fires after the commit, not before it.

 

Another reason for using PSoS is that, by pushing the logging off to the server, the user's context doesn't need to change. There's no need to spawn a new window and/or change layouts to perform the logging. (If we had support for INSERTs in ExecuteSQL, then this would be a lot easier to pull off.)

 

In any case, my hope is that stepping through the script will be a lot easier with the modular version of EA. We'll see.

 

-- Tim