Vorab: Falls Sie tatsächlich diese ganze Objekt-Kaskade benutzen (und es nicht nur aus Übersichtlichkeitsgründen hier im Beitrag so geschrieben haben): Bitte benutzen Sie UNBEDINGT Objektvariablen. So eine Kaskade legt für jeden Kaskadenschritt eine Objekt-Variable an (und verwirft diese danach direkt wieder) - jedes Mal. Das ist zum einen richtig schlimm für die Performance, zum anderen könnte das auch eine pot. Ursache für den von Ihnen beschrieben Effekt sein, weil beim Setzen von Feldern eine Abfolge von Methoden auf ein-und-dasselbe Scripting-Record-Objekt angewendet werden muss. Siehe unten.
Zur Frage: CurrentInputForm ermöglicht den direkten Zugriff auf die Eingabeelemente der Eingabemaske. Schreibender Zugriff - sofern der:die Anwender:in im Bearbeiten-Modus ist - setzt den Inhalt nur im Control, die Änderung wird daher auch direkt angezeigt (gleichsam als wäre der Wert manuell per Tastatur eingegeben worden), der Inhalt ist NICHT autom. im Datensatz gespeichert. Wenn der:die Anwender:in danach nicht speichert, dann ist die Änderung hinfällig. Typischerweise benutzt man CurrentInputForm in Scripten, die Benutzer:innen kompliziertere Änderungen beim Bearbeiten des aktuellen Datensatzes in der Eingabemaske abnehmen sollen, aber die eigentliche Hoheit der Änderung („Speichern“) weiterhin den Benutzer:innen überlassen bleiben sollen/müssen. In Scripten dieses Kontextes ist auch das pragma „keep-editmode“ wichtig (siehe SDK Doku).
CurrentRecord ermöglicht den Zugriff auf einen in der Datenbank gespeicherten Datensatz. Dieser muss nicht unbedingt visuell dem Benutzer gerade präsentiert werden! Er kann z.B. auch über ViewConfig.CreateRecordSet und einem entsprechendem Such-Filter komplett unsichtbar aus einer ganz anderen Ansicht stammen, komplett unabhängig von der in der Oberfläche gerade dargestellten Ansicht und Datensatz.
Das Setzen eines Feldes erfolgt immer nach folgendem Schema:
Record.Lock();
Record.SetContentsByName("Feld", "Wert"); // oder SetContentsValueByName
Record.Save();
Record.Unlock();
Essentiell wichtig ist ein sauberes Fehlerhandling durch Check des Rückgabewertes mindestens bei Lock und Save. Ersteres schlägt fehl, wenn der:die Benutzer ggf. keine Rechte hat, diesen Datensatz zu ändern. Save schlägt fehl, wenn z.B. der Datenbankserver aufgrund von irgendwelchen Integritätsregeln (Constraints) das Speichern ablehnt.
Was jetzt noch fehlt, FALLS es sich um einen visuellen auch gerade tatsächlich dargestellten Datensatz handelt: die Anzeige zu aktualisieren (analog zu ‚Fenster > Aktualisieren‘). Dies geschieht durch die Update Methode für das aktuell angezeigte ActiveView Objekt.
Ein mitgeliefertes C# Scripting Beispiel finden Sie in Ihrem cRM Installationsordner unter .\Scripts\Examples\C#Script\ChangeFieldContent.csscript. (Bitte aber noch das Fehlerhandling ergänzen, best-practice siehe SDK Doku bei der LockMethode.)
Wenn Sie jetzt mit einer Objekt-Kaskade arbeiten, statt einer Record Variablen, dann laufen Lock, SetContentsByName und Save in drei unterschiedliche (nämlich jeweils temporäre) Scripting-Record-Objekte und nicht auf ein-und-dasselbe. Und da die Save Methode für „ihr“ temporäres Objekt keinerlei Änderungen „bemerkt“ (weil das SetContents ja in ein anderes temp. Objekt gelaufen ist), gibt es aus dessen Sicht auch nichts zu speichern.
Ich hoffe, Sie können damit das Problem einkreisen und lösen. 
