[Gelöst] Dataport CallFieldValidate geht nicht

Hallo,

ich habe einen Dataport erstellt. Funktioniert auch soweit alles.

Jedoch wird der On Validate Trigger nicht ausgeführt.

Die Eigenschaft CallFieldValidate habe ich auf True gesetzt.

Warum geht das nicht?

Gruß
Ralf

Zuletzt geändert von ralf5 am 4. November 2010 12:51, insgesamt 1-mal geändert.

Der Trigger macht nur bei einem Import Sinn bzw. wird nur dann ausgeführt. Führst du einen Import durch?
Wenn ja:
Wie hast du überprüft, dass der Trigger nicht ausgeführt wird?

Ja, ich mache einen Import.

Der OnValidate Trigger beim Feld: Namen füllt das Suchfeld. Nach dem Import ist dieses aber leer.

Ist dein veröffentlichter Dataport aktuell? Dort fehlt nämlich die gesetzte Eigenschaft CallFieldValidate.

Der OnValidate Trigger beim Feld: Namen füllt das Suchfeld. Nach dem Import ist dieses aber leer.

Dies ist der Trigger im Standard:

Code:

IF ("Search Name" = UPPERCASE(xRec.Name)) OR ("Search Name" = '') THEN
  "Search Name" := Name;

Der Suchbegriff wird demnach nur unter bestimmten Bedingungen gesetzt.
Testest du mit einem neu anzulegenden Debitor oder mit einem bestehenden? Bei einem bestehenden musst du dem Quelltext nach zuerst "Search Name" leeren (OnBeforeImportRecord).

Ist dein veröffentlichter Dataport aktuell? Dort fehlt nämlich die gesetzte Eigenschaft CallFieldValidate.

Ja, sorry in dem DP fehlt das noch. Die Eigenschaft CallFieldValidate ist aber = Yes.

..Trigger im Standard... Testest du mit einem neu anzulegenden Debitor oder mit einem bestehenden?...

Ich habe es einfach mal versucht indem ich im Standard Trigger die If Bedingung entfernt habe also:

Code:

"Search Name" := Name;

Geht aber weder mit einem neu anzulegenden Debitor als auch mit einem bestehenden nicht

Fragen wir doch mal den Debugger - landest du überhaupt im VALIDATE-Trigger?

Und die Standard-Dataport-Frage: wird er aus dem Designmodus gestartet?

Fragen wir doch mal den Debugger - landest du überhaupt im VALIDATE-Trigger?

Ja, er landet im VALIDATE-Trigger
Ich habe mal zusätzlich eine MESSAGE(Name); eingefügt. Die MESSAGE wird auch angezeigt.

Der Suchname wird aber nicht gefüllt.


Jetzt verstehe ich gar nichts mehr

Und die Standard-Dataport-Frage: wird er aus dem Designmodus gestartet?

Ja, nach schmerzlichen 4 Stunden und intensivem Studium aller Hilfedateien weiß ich, dass im Designmodus keine Daten geändert werden

Der Suchname wird aber nicht gefüllt.

Ist das der Dataport, bei dem nur bestehende Datensätze aktualisiert werden sollen? Oder geht es jetzt um was anderes?
Wenn AutoSave = No ist, denke daran, dass du noch selbst ein MODIFY bzw. INSERT (wenn gewünscht) im OnAfterImportRecord ausführen musst.
Der Trigger scheint ja an sich zu funktionieren.

Ist das der Dataport, bei dem nur bestehende Datensätze aktualisiert werden sollen? Oder geht es jetzt um was anderes?

Nein, es geht noch um den gleichen DP.

Also ums nochmal klarzustellen, ich möchte in der Tabelle Customer:
1. den Namen bei bestehenden Customer ändern.
2. keine neuen Customer anlegen (falls mal ein Customer gelöscht wurde) auch keinen Datensatz ersetzen
3. das der OnValidate-Trigger vom Namen ausgeführt wird, so dass im SuchFeld der Name steht.

Ich habe jetzt folgenden Stand:
Positiv:
1. Der Name wird aktualisiert
2. Es werden keine neuen Customer angelegt

Negativ:
1. Der Datensatz wird ersezt, d. h. das Suchfeld und alle anderen Felder sind danach leer

Hier der aktueller Stand des DP:

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Das musst du durch Programmierung im OnAfterImport-Trigger lösen:
Hole anhand der importierten Daten den Debitor (in eine neue Recordvariable, sagen wir: Cust), validiere dort Cust.Name und führe anschließend ein Cust.MODIFY aus.

Sehe ich das richtig, das ich keinen Dataport erstellen kann, der meinen -einfachen- Anforderungen enspricht, ohne zusätzlich zu programmieren?

Sehe ich das richtig, das ich keinen Dataport erstellen kann, der meinen -einfachen- Anforderungen enspricht, ohne zusätzlich zu programmieren?

Naja, also das bisschen würde ich noch nicht mal "Programmieren" nennen
Mit den Dataports lässt sich ohne Extracode schon jede Menge abbilden. Programmiere mal einen Datenimport nur mit einer Codeunit statt Dataport, damit du den Dataport wieder zu schätzen weißt
Du hast lediglich eine Spezialanforderung, die sich mit Eigenschaften nicht abbilden lässt , aber mit wirklich geringen Mitteln realisieren lässt.

Irgendwie habe ich das doch mal hinbekommen Ich glaube, dass es auf die Reihenfolge der Dataportfields ankam. Wenn ich zB eine Artikelnummer importiere, diese auf CallFieldValidate=Yes steht und damit die Beschreibungen gefüllt werden sollen, überschreibt der Dataport die Felder wieder, wenn dafür danach leere Werte folgen. Deswegen hatte ich das zu validierende Feld ganz ans Ende der Liste mit den Dataport-Fields gelegt. Ohne Gewähr, weil das schon so lange her ist

Programmiere mal einen Datenimport nur mit einer Codeunit statt Dataport, damit du den Dataport wieder zu schätzen weißt

OK, aber aus der Steinzeit sind wir ja wohl raus, sollte man meinen

Du hast lediglich eine Spezialanforderung

Ich hoffe doch, dass das aktualisieren von vorhandenen Datensätze noch keine Spezialanforderung darstellt. Das sollte eigentlich zum einfachen Standard gehören

Naja, also das bisschen würde ich noch nicht mal "Programmieren" nennen

Dann geb ichs halt auf und schreibe ein bischen Text in die CodeUnit, damit das funktioniert

Danke und Gruß
Ralf

Ich hoffe doch, dass das aktualisieren von vorhandenen Datensätze noch keine Spezialanforderung darstellt. Das sollte eigentlich zum einfachen Standard gehören

Dataports wurden primär dafür geschaffen, Datensätze zu erzeugen (INSERT) statt nur zu aktualisieren (MODIFY). Dies ist z.B. wichtig bei Datenübernahme aus einem Altsystem.

Irgendwie habe ich das doch mal hinbekommen Ich glaube, dass es auf die Reihenfolge der Dataportfields ankam. Wenn ich zB eine Artikelnummer importiere, diese auf CallFieldValidate=Yes steht und damit die Beschreibungen gefüllt werden sollen, überschreibt der Dataport die Felder wieder, wenn dafür danach leere Werte folgen. Deswegen hatte ich das zu validierende Feld ganz ans Ende der Liste mit den Dataport-Fields gelegt. Ohne Gewähr, weil das schon so lange her ist

Das Feld ist beim Import am ende der Liste, da ich nur die Felder "No." und "Name" habe, in selbiger Reihenfolge.

Das musst du durch Programmierung im OnAfterImport-Trigger lösen:
Hole anhand der importierten Daten den Debitor (in eine neue Recordvariable, sagen wir: Cust), validiere dort Cust.Name und führe anschließend ein Cust.MODIFY aus.

Ich denke, ohne diesen Ansatz (verdrängt? ) kommst du nicht weiter.
Die Eigenschaften wie CallFieldValidate machen nur dann Sinn, wenn im Dataport (fast) alle Debitorenfelder gefüllt werden. Dataports wurden für so partielle Updates nicht gemacht.

Kann sein, dass das nur beim Import und nicht beim Update ging, ich weiß es halt nicht mehr. Es dürfte aber seinen Grund haben, dass ich das seitdem einen Import mit Validates immer so mache, wie Natalie es beschreibt.

Kann sein, dass das nur beim Import und nicht beim Update ging, ich weiß es halt nicht mehr. Es dürfte aber seinen Grund haben, dass ich das seitdem einen Import mit Validates immer so mache, wie Natalie es beschreibt.

Also, jetzt habe ich mal einige Einstellungen durchgetestet und komme zu folgendem Ergebnis:

1. Wenn ich einen neuen Dataport erstelle und die Standardeinstellungen verwende funktioniert CallFieldValidate gar nicht. Für mich ganz klar ein Fehler.
2. Nur wenn AutoUpdate = No ist funktioniert es. Dann wir nur bei neuen Datensätzen der OnValidate Trigger ausgeführt.
3. Damit dieser auch bei vorhandenen Datensätzen ausgeführt wird muss noch ein Modify in das OnAfterImportRecord() Ereignis.

Wenn nur vorhandene Datensätze geändert werden sollen muss AutoSave = No sein

Das unser Partner die Tabelle Region verwendet um Daten im Customer zu ändern wundert mich jetzt auch nicht mehr

Danke für die Hilfe
Gruß
Ralf

Das unser Partner die Tabelle Region verwendet um Daten im Customer zu ändern

Ist das irgendwie Trick17 oder seh ich die Idee hinter dem Workaround eueres NSCs nicht?
Was hat Customer mit Country/Region außer einer 1:1-Beziehung zu tun?

ralf5 hat geschrieben:

Das unser Partner die Tabelle Region verwendet um Daten im Customer zu ändern

Ist das irgendwie Trick17 oder seh ich die Idee hinter dem Workaround eueres NSCs nicht?
Was hat Customer mit Country/Region außer einer 1:1-Beziehung zu tun?

Ich habe das nicht geschrieben . Und du hast pro Land nur einen Kunden?

ralf5 hat geschrieben:

Das unser Partner die Tabelle Region verwendet um Daten im Customer zu ändern

Ist das irgendwie Trick17 oder seh ich die Idee hinter dem Workaround eueres NSCs nicht?
Was hat Customer mit Country/Region außer einer 1:1-Beziehung zu tun?

Ich habe das nicht geschrieben . Und du hast pro Land nur einen Kunden?

Ahso, ich dachte, du hättest deren Code irgendwie vorliegen und könntest den Workaround erläutern.

Und ja, du hast recht, zwischen Country/Region : Customer gibt's eine 1:n Beziehung.

Ist das irgendwie Trick17 oder seh ich die Idee hinter dem Workaround eueres NSCs nicht?

Das Problem war, das gelegentlich ein Customer angelegt wurde der eine leere ID hat. Also hat unser NSC die Tabelle Region genommen weil wir diese Tabelle nicht nutzen. Wenn da jetzt ein leerer DS drinnsteht interressierts keinen.

Nur mal so ne nicht böse gemeinte Nebenfrage: Wie wird man eigentlich Partner... geht man da zu Aldi und kauft eine Lizenz?

Gruß
Ralf