Ich habe ein massives Problem mit Triggern, die ich in TB2011 erstellt habe und die mit Map2014 nicht mehr wie gewohnt laufen und Datenschrott erzeugen!

Leider musste ich feststellen, dass If-Anweisungen wie „If Updating (‚GEOM‘)“ bzw. die Einschränkung von Triggern auf gewisse Tabellen-Attribute nicht mehr funktionieren, weil offensichtlich grundsätzlich alle Attribute einer Maske bei einem Update übergeben werden.
Mir ist bewußt, dass sich der Support bei solchen Problemen nicht zuständig fühlt, aber wenn man 1 und 1 zusammenzählt, dann wird ein ganz anderes Problem sichtbar:

In den Standard-Rules von Map werden genau solche Statements verwendet, so dass alle diese Rules bei jedem Update anspringen!!!

Genau das wird 100%ig auch bei Fehler 08617079 passieren, wo die AutoLabels in ihrer Position angepasst werden, wenn irgend ein Attribut des Label-Parents verändert wird.

Das Problem habe also nicht nur ich mit meinen eigenen Triggern, sondern jeder Map-Kunde. Bei kleineren Projekten mag das nicht auffallen, aber ich gehe davon aus, dass dieser Umstand auch einen größeren Beitrag zu unseren Performance-Problemen beiträgt. Wenn bei allen Updates plötzlich viel mehr Trigger losfeueren als geplant, kann man sich vorstellen, dass das etwas länger dauert.

Des Weiteren habe ich damit ein großes Problem, weil ich in letzter Zeit häufiger Datenfehler beobachten musste, deren Ursache ich zunächst nicht feststellen konnte. Jetzt weiß ich, dass es daran liegt, dass jetzt auch Aktionen durchgeführt werden, die explizit nur bei bestimmten Updates passieren sollten. Augenscheinlich sieht in den Triggern ja noch alles richtig aus, aber wenn da ein ganz anderes Statement abgeschickt wird, kommt natürlich auch etwas ganz anderes heraus.

Teilweise kann man die Trigger ja umschreiben und :new.XY != :old.XY verwenden, um richtig zu reagieren, aber das geht z.B. nicht bei GEOM-Spalten. Dazu bräuchte man eine Funktion, die jedes Element des ORDINATE_ARRAY vergleicht, um festzustellen, ob sich die Geometrie wirklich verändert hat. Das ist Wahnsinn, weil es extrem auf die Performance geht.

Der Fall wurde mit höchst möglicher Priorität an Autodesk übermittelt und mit der Forderung, den alten Zustand wieder herzustellen. Updates dürfen nur die Attribute enthalten, die auch wirklich verändert wurden!

BTW: Das ist einer der Punkte, den ich in den ebenso geforderten „erweiterten Releasenotes“ erwartet hätte. Das ist eine MASSIVE Veränderung der Basisfunktionalitäten, die DEUTLICH kommuniziert werden muss, damit kein Datenschrott erzeugt wird und die benutzerspezifischen Anpassungen neu justiert werden können, bevor man in Produktion geht.

GordenKock
Author: GordenKock