Nein, ein Anfordern eines CurrentRecords speichert nichts implizit, automatisch.
Wenn Sie aktuell einen Datensatz bearbeiten und währenddessen diesen „Undo“ Button klicken, würde das Script gestartet und wenn in dem Script keine speziellen Vorkehrungen getroffen wurden (s.u.), dann würde jetzt erstmal die Frage kommen, ob man (vor der Scriptausführung) den Datensatz zunächst einmal speichern möchte. Wenn dies bejaht wird, haben Sie eine Speicherung „vor Lock“ (nämlich bevor das Script überhaupt losläuft).
Es gibt zwei Anweisungen, mit denen man im Script das o.a. Verhalten ändern kann:
<!--#pragma keepeditmode-->
Würde die o.a. Frage nach dem Speichern unterdrücken und einfach das Script direkt starten. Das wäre in Ihrem Fall aber schlecht, weil Sie ja im Script ja selber ebenfalls den Datensatz sperren, verändern und speichern. Das verträgt sich nicht. Das verträgt sich nur, wenn man mit CurrentInputForm(2) noch ein paar Felder in der Eingabemaske setzen (als hätte der:die Anwender:in es selbst eingetippt), aber die Hoheit über die Speicherung weiterhin dem Menschen überlassen will. Oder mit einem CurrentInputForm Wert etwas „ganz anderes“ machen möchte, aber eben den aktuellen Datensatz nicht über CurrentRecord verändert/speichert.
<!--#pragma autosave-->
Würde die o.a. Frage nach dem Speichern unterdrücken und den Datensatz einfach so wie er gerade ist abspeichern und dann das Script starten. Dies würde genau Ihrem Szenario entsprechen. Ist dieses #pragma in Ihrem Script?
Was mich etwas irritiert, ist, dass Sie von TRIGGER sprechen. Meinen Sie Datenbanktrigger? Sie dürften konzeptionell die „speziellen“ Felder überhaupt nur „sichern“, wenn sie überhaupt Teil der gerade gespeicherten Änderung sind. Sonst würde ja JEDES Speichern, auch wenn nur irgendein ganz anderes unbeteiligtes und irrelevante Feld kurz geändert worden wäre, egal durch wen oder was, sofort die Sicherung killen, wenn Sie einfach „stupide“ immer den aktuellen Inhalt der Spezialfelder bei jedem Speichern einfach in die korrespondierenden Backup-Felder umkopieren. Das darf nur passieren, wenn sie gerade auch nen neuen Inhalt kriegen/gekriegt haben. Das hat mit Ihrem Undo Script gar nichts zu tun. Verstehen Sie was ich meine?
Um dies zu realisieren, müssen Sie sich ein wenig in die Details der Trigger-Programmierung reinfuchsen.
Hier mal ein („as-is“ ungetestetes) Snippet als Vorlage (MSSQL) - für mehr fehlen uns im Rahmen des „normalen“ Supports leider die Ressourcen, da müssten wir dann doch irgendwie den Bogen zu unserem Dienstleistungsangebot geschlagen kriegen. 
Der Trigger „beobachtet“ 4 Felder (Street, ZIP, City und Country) in der Tabelle „Companies“ und würde nur die entscheidende Aktion (siehe „TODO“) nur lostreten, wenn eines dieser Felder geändert würde.
Hier klicken für MSSQL Trigger Rumpf-Beispiel (Nerd-Alert!)
ALTER TRIGGER [dbo].[cmbt_trigger_BackupAdressFields_Companies] ON [dbo].[Companies]
AFTER UPDATE
AS
DECLARE
@ID uniqueidentifier,
@deletedCount bigint,
@insertedCount bigint,
@reason int
, @Street_New nvarchar(max), @Street_Old nvarchar(max), @ZIP_New nvarchar(max), @ZIP_Old nvarchar(max), @City_New nvarchar(max), @City_Old nvarchar(max), @Country_New nvarchar(max), @Country_Old nvarchar(max)
BEGIN
SET NOCOUNT ON;
-- check what kind of trigger was fired
SELECT @deletedCount = COUNT(*) FROM deleted
SELECT @insertedCount = COUNT(*) FROM inserted
DECLARE
@Street_Updated [bit]
, @ZIP_Updated [bit]
, @City_Updated [bit]
, @Country_Updated [bit]
IF UPDATE([Street])
SET @Street_Updated = 1
IF UPDATE([ZIP])
SET @ZIP_Updated = 1
IF UPDATE([City])
SET @City_Updated = 1
IF UPDATE([Country])
SET @Country_Updated = 1
-- means UPDATE
IF @deletedCount = @insertedCount
SET @reason = 2
-- means DELETED
IF @insertedCount = 0 AND @deletedCount > 0
SET @reason = 3
-- means INSERT
IF @deletedCount = 0 AND @insertedCount > 0
SET @reason = 1
IF (@reason = 2)
BEGIN
IF ((@Street_Updated = 1) OR (@ZIP_Updated = 1) OR (@City_Updated = 1) OR (@Country_Updated = 1))
BEGIN
-- create cursor for each record
DECLARE record_cursor CURSOR LOCAL FAST_FORWARD FOR SELECT "ID" , "Street", "ZIP", "City", "Country" FROM inserted
OPEN record_cursor
FETCH NEXT FROM record_cursor INTO @ID , @Street_New, @ZIP_New, @City_New, @Country_New
WHILE @@FETCH_STATUS = 0 -- while FETCH statement is successful
BEGIN
IF ((@Street_Updated = 1) OR (@ZIP_Updated = 1) OR (@City_Updated = 1) OR (@Country_Updated = 1))
BEGIN
SELECT @Street_Old = Street, @ZIP_Old = ZIP, @City_Old = City, @Country_Old = Country FROM deleted WHERE ID = @ID
IF ((@Street_New <> @Street_Old) OR (@ZIP_New <> @ZIP_Old) OR (@City_New <> @City_Old) OR (@Country_New <> @Country_Old))
BEGIN
-- TODO: UPDATE corresponding backup-field(s) with ..._Old value(s) WHERE ID = @ID
END
END
-- go to next
FETCH NEXT FROM record_cursor INTO @ID , @Street_New, @ZIP_New, @City_New, @Country_New
END
CLOSE record_cursor
DEALLOCATE record_cursor
END
END
END
Viel Erfolg! 
