Also zunächst mal zu deinem Trigger-Code ein paar Anmerkungen:
a) Dein Trigger feuert nicht bei DELETE weil das Schlüsselwort fehlt. Selbst wenn es da wäre machst du einen INNER JOIN auf INSERTED, wo bei DELETE-Operationen keine Datensätze wären. Das ist ja vielleicht gewollt und dann auch nicht verkehrt aber später fragst du mit count() = 0 ab ob es sich um einen DELETE-Vorgang handelt, das wäre dann überflüssig.
b) Dein UPDATE-Statement könnte problematisch sein, da bin ich jetzt aber nicht sicher (vermutlich nicht). Wenn das läuft dann gut, wenn nicht, dann dreh mal die Tabellen um:
Code:
FROM [dbo].[ADDRESSES] a
INNER JOIN Inserted i
Auch das hinter UPDATE-Statement würde ich entsprechend anpassen, ich bin nicht sicher ob hier
[UPDATE]Alias
SET ...
FROM Tabelle Alias[/CODE]
funktioniert. Ist wieder mein Bauch der meckert aber ich verwende Aliase nur für die Tabellen die ich joine, die Tabelle im FROM die ich update behält ihren Namen.
c) Ganz fieser Fehler:
Du füllst Variablen, noch dazu schreibst du den Inhalt dieser Variablen dann wieder in die Tabelle ohne den Primärschlüssel abzugleichen. Das geht immer genau solange gut, wie in INSERTED genau ein Datensatz steht. Wenn du ein UPDATE machst das mehrere Zeilen betrifft feuert der Trigger genau einmal und nimmt die Daten eines beliebigen Datensatzes in die Variablen und schreibt sie in alle! anderen Datensätze. Auch wenn dein CRM i.d.R. nur einen Datensatz gleichzeitig aktualisiert kann das ganz schnell knallen wenn keiner mehr an den Trigger denkt. Du solltest auf jedenfall direkt das UPDATE machen, ohne die Variablen.
d) Den UPDATE-Code verstehe ich auch nicht so recht. Du hängst an Ortsteil ein Leerzeichen an wenn Ortsteil 0 Zeichen lang ist. Das wird dann durch ltrim() abgeschnitten... Was ist denn wenn Ortsteil oder Straße NULL ist?
e) Dein eigentliches Problem resultiert eventuell aus NULL-Werten beim anlegen des Datensatzes. Kann es sein das die Spalten erst durch einen anderen Trigger befüllt werden? Dann hast du schlechte Karten wegen der Anzahl der Trigger und der Reihenfolge.
Mal ein anderer Ansatz:
Ließe sich das ganze nicht auch per View realisieren? Deine Schnittstelle würde dann auf die View und nicht die ADRESSES Tabelle zugreifen.
Zu Conbra:
Wir standen vor gefühlt 100 Jahren vor der Wahl. Ich habe mich dann für Combit statt Cobra als CRM entschieden weil das Datenmodell von Cobra (zumindest damals) total schlecht war. Im Prinzip nichts normalisiert sondern das meiste in einer Tabelle. Daher sind die Trigger vermutlich von Cobra selbst oder wurden die für euer Projekt entwickelt?
Im wesentlichen ist Combit recht ähnlich, da arbeite ich natürlich auch mit Triggern. Habe aber das ganze Datenmodell sauber aufgebaut, Schnittstellen (z.B. zu Outlook) bilde ich auch per View ab.