This article uses an idea first mentioned in "Validation Rules Don't Always Mean Stop!".  

The example 'UpdateRecord' event function below will write out into a log file which fields have changed.  It won't write every field in the screen so we first need to know what fields are in the screen and then examine each field in turn. To do this I've used the fact that the screen object (EntryGroup block) is an enumerable object.

function UpdateRecord()

var ForReading = 1, ForWriting = 2, ForAppending = 8; 
var TristateUseDefault = -2, TristateTrue = -1, TristateFalse = 0; 
var mySystemObject = new ActiveXObject("Scripting.FileSystemObject"); 
var myFile = mySystemObject.GetFile("c:/customlogs/TEST.TXT"); 
var myFileTextStream = myFile.OpenAsTextStream(ForAppending, TristateUseDefault); 
var oldName = ""; 
var myBlock = CRM.GetBlock("CompanyBoxLong"); 
var myE = new Enumerator(myBlock); 
while (!myE.atEnd()) 
oldName = CRM.GetContextInfo("company",myE.item()); 
if (oldName != Values(myE.item())) 
myFileTextStream.WriteLine(oldName +"/"+Values(myE.item())+" changed by "+CurrentUser.user_logon); 


This script is only a proof of concept and could be much improved.  If we wanted to unify the custom log with the other logs in Sage CRM we could do that using the idea discussed in the articles "Write to the CRM logs in a server-side script" or "Adding Additional Custom Logs to Sage CRM".