Kontakte werden dupliziert

Hallo,

wir haben momentan das Problem, dass die Kontakte in der Tabelle „Contacts“ dupliziert werden.
Unsere Solution sieht so aus:

  • Die Solution basiert sich auf combit_Lager5
  • Wir haben die „Contacts“-Tabelle erweitern mit einer internen KontaktNr.
  • Wir haben die „Companies“-Tabelle erweitern mit einer internen FirmaNr.
  • Wir haben einen Erfassungsmaske-View erstellt, damit man Kontakte eingeben kann
  • Durch ein Trigger werden die Kontakte angelegt und die Firmen mit dem Kontakten verknüpft (durch FirmaNr und KontaktNr)

Als wir die Firmen noch nicht verknüpft haben, hat es alles funktioniert als erwartet.
Als wir die Firmen verknüpft haben, werden die Kontakte dupliziert. Einmal mit den Daten, dass wir eingegeben haben und einmal mit „extra“ Daten. Zum Beispiel im Feld „Address“ wird die Adresse der Firma geschrieben.

Wir vermuten, dass die Triggers [cmbt_Trigger_Solution_Contacts] und [cmbt_trigger_watch_Contacts] eine Rolle spielen aber wir wollten sie nicht einfach deaktivieren, falls etwas „Kaputt“ geht.

Wie können wir diesen Verhalten deaktivieren? oder die Duplizierung vermeiden?

Vielen Dank!

LG
David

„cmbt_trigger_watch_Contacts“ kann man ausschließen, der schreibt nichts in die „Contacts“ (der wird übrigens autom. durch die Anwendung selbst generiert (und auch deaktiviert), und zwar für jede Tabelle, in der bei der darauf basierenden Ansicht die Option „Datensatzüberwachung“ aktiviert ist. Bitte nicht anfassen.

„cmbt_Trigger_Solution_Contacts“ ist Teil der Solution und aktualisiert bestimmte Felder und sorgt zum Beispiel automatisch für den „Anschriften“-Block, der dann trivial an allen Stellen (Etikett/Serienbrief etc.) genutzt werden kann, ohne sich den Block selbst aus den Einzelkomponenten zusammenbauen zu müssen, indem er den Block aktualisiert, wenn sich eine in den Adressblock gehörenden Einzelkomponenten geändert hat (Anrede, Nachname etc.). Soweit ich das auf die Schnelle weiß, INSERTED der keine neuen Datensätze in die Tabelle. Würde ich erstmal ausschließen.

Da Sie ja hier „hardcore“ jetzt eine View haben und dort (vmtl.) einen „instead“ Trigger gebaut haben, würde ich doch erstmal in Ihrem Trigger suchen, ob der z.B. aus irgendeinem Grund sich rekursiv selbst nochmals auslöst (NESTING_LEVEL!) oder irgendwas in der Art. Das als Außenstehender zur finden, wird sehr mühsam. :frowning:

Darf ich nochmal einen Schritt zurückgehen: Was wollen Sie denn eigentlich lösen?

Eine komfortable Kombinationseingabemöglichkeit von Kontakt UND Firma gibt es bereits mit der Ansicht „Adressen“ inkl autom. Splitting. Daher weiß ich auch, dass ein INSTEAD Trigger nicht ganz trivial ist :innocent: , das ist nämlich einer.

Die Erfassung eines neuen Ansprechpartners zu einer Firma würde „typischerweise“ über die Firma erfolgen, d.h. man sucht die Firma (z.B. über die Firmennummer) und wählt dann „Neuer Ansprechpartner“. Damit wäre der neu eingegeben Kontakt vollautomatisch direkt mit der Firma bereits verknüpft.

Wenn Sie eine einfache Firmenzuordnung anhand einer Firmennummer vom Kontakt aus realisieren möchten, dann könnten Sie entweder den o.a. „cmbt_Trigger_Solution_Contacts“ erweitern, indem Sie dann bei INSERT und UPDATE (wenn das Firmennummer-Feld Teil des Updates ist) dann die korrespondierende „ID“ aus „Companies“ holen und in „CompanyID“ eintragen. Sinnvoll wäre auch spiegelbildlich andersherum: wenn die „CompanyID“ auf einen neuen Wert gesetzt wird (z.B. bei Nutzung einer der o.a. Wege) dann hingegen die Firmennummer entsprechend nachgezogen wird, damit die beiden Felder immer synchron sind.

Ansonsten können Sie aber auch eine Schaltfläche „Firma verknüpfen“ in der Eingabemaske von „Kontakte“ spendieren und im dahinterliegenden Script machen Sie ein DialogSelectRecord auf das Firmen-RecordSet. Dann kann der:die Anwender:in über Suchmöglichkeiten seiner:ihrer Wahl in dem Dialog selber die richtige Firma finden (zum Beispiel eben auch die Firmennummer) und das Script liest aus dem ausgewählten Datensatz dann Firmennummer und ID aus und setzt diese in den vorliegenden Kontakte-Datensatz per CurrentInputForm(2).SetContentsValueByName in „CompanyID“ und Firmennummer rein.

Im Script sollten Sie unbedingt <!--#pragma keepeditmode--> verwenden, weil sonst der Klick auf den Button zuerst einmal den Datensatz speichern wollen würde, was im vorliegenden Anforderungsfall ja gerade kontraproduktiv wäre.

Ein weiterer Ansatz wäre auf das Feld „Firmennummer“ eine Folgeverknüpfung mit einem Script zu legen, und das Script holt dann die korrespondierende Firmennummer und schreibt es ebenfalls per CurrentInputForm(2).SetContentsValueByName in das entsprechende Feld. Das würde den Klick auf die Schaltfläche sparen. Man würde „4711“ eintippen und TAB oder ENTER drücken und das Script würde loslaufen, die Firma wäre direkt zugeordnet, aber das Speichern oder eben auch Verwerfen der Änderung bliebe weiterhin den Anwender:innen überlassen.

Oder Sie bauen einen kleinen eigenen Erfassungdialog (DialogForm), den Sie oben im Screenshot der Ansicht „Adressen“ sehen. Das ist komplett Script-gesteuert, d.h. im Anschluss können Sie die dortigen Formulareingaben per Script auslesen und können das direkt für die scriptgesteuerte Datensatz-Neuanlage in der Ansicht „Kontakte“ mit den entsprechenden Werten nutzen.

Sie merken schon: es gibt im combit CRM Framework zig Möglichkeiten, effektive und ergonomisch sinnvolle Lösung für fast jedes Szenario zu bauen, alle haben halt auch ihre Vorteile und Nachteile.

Sie können mal in der Dokumentation (Benutzerhandbuch, Solutionhandbuch und auch SDK Dokumentation nach den Stichwörtern oben mal suchen und sich da ein bisschen einlesen.

Bei Fragen: einfach Fragen. Bei der Fehlersuche in Ihrem instead-of Trigger muss ich vermutlich passen. :slight_smile:

Happy Weekend!

Hallo Björn,

vielen Dank für Ihre ausführliche Antwort und sorry für meine verspätete Antwort.

Ich musste mein „instead“ trigger erweitern und ich konnte mich nicht mit diesem Problem weiterbeschäftigten. Heute wollte ich aber weitermachen und zu meiner Überraschung tritt das Problem nicht mehr auf :scream:.

Ich vermute es war tatsächlich das NESTING_LEVEL, wie Sie schon meinten.

Vielen Dank noch für die unterschiedliche Umsetzungsoptionen! Das hat mir ein paar Ideen gegeben für anderen Bereichen :wink:

LG

David

© combit GmbH