Upgrade von V 7.3 auf 7.4 bzw. 7.5

[loeweadolf]

An alle, die sich zu dem Thema gemeldet haben: Vielen Dank.

Falls jemand noch weitere Erfahrungen gemacht hat, hier bitte mitteilen.

Eine Frage noch an Andreas-Prouza: Kannst du mal bitte ein Beispiel von "schmutzigen Daten"
nennen?


Weiterhin habe ich folgende Frage :
Gibt es Probleme bei SQL-Triggern ?

[Andreas_Prouza]

Eine Frage noch an Andreas-Prouza: Kannst du mal bitte ein Beispiel von "schmutzigen Daten"
nennen?

Ich meine mich erinnern zu können, dass es bei Daten-Typ Konvertierungen war.
Hast du in das "Memo to user" vom Robi geschaut?
Ich glaube es war beim Wechsel auf 7.5.

[Robi]

Sql ist eigendlich immer etwas

Unsaubere Abfragen z.b.:
kann mich erinnern das wir ein alpa Feld, das nur numerische Inhalte hatte, ohne ' abgefragt hatten
.. where Feld = 1234

nach einem Releaswechsel gingen all diese Abfragen nicht mehr und mussten auf
... where Feld = '1234' geändert werden.

Natürlich hätte das von vornherein anders gemacht werden müssen, aber es ist halt nicht aufgefallen und hatte funktioniert.

[loeweadolf]

Vielen Dank an alle.

Und speziellen Dank auch an ROBI für den Link zum IBM-Memo.

[Fuerchau]

An obigen Fall kann ich mich auch erinnern, da der Optimizer einfach anders arbeitet.
In der vorherigen Version wurde die Konstante an den Typ des Verlgeichsfeldes angepasst, also automatisch '1234' genommen.
In der neuen Version wird das Vergleichsfeld auf den Typ der Konstante gecastet und wenn das Feld dann, wie in diesem Fall, nicht numerisch ist, fliegt der SQL um die Ohren.
Dies sieht man im Debugger dann im Joblog, da der Feldname als Cast-Ausdruck geoutet wird, den man ja gar nicht eingegeben hatte.
Ansonsten merkt man da auch nichts, außer, dass ein Index nicht verwendet wird und der SQL ggf. erheblich länger benötigt.
Aufgefallen ist das halt bei User-SQL's, die z.B. einen Mandanten (Infor) gerne mit
TEFIRM = 1
abfragen obwohl das Feld ja vom Typ char(1) ist. Als dann eine Firma "A" angelegt wurde, liefen viele Abfragen nicht mehr.