Primärschlüssel einer Standardtabelle um ein Feld erweitern
14. August 2007 17:58
Im Rahmen einer Kundenanpassung komme ich nicht herum, die Tabelle 5765 (Erwartete Lagerbewegung) um ein neues Optionsfeld zu erweitern. Dieses neue Feld wird dem Primärschlüssel angehängt.
Habt ihr Erfahrung mit Primärschlüsselerweiterungen? Worauf muss ich ggf. achten? Vielleicht besonders im Zusammenhang mit SQL-Datenbanken?
Getan habe ich folgendes: Im NDT abfragen, wo auf diese Tabelle ein GET, FINDFIRST, FINDLAST angewendet wird. Insbesondere das GET ist dann um ein FINDSET mit anschließender REPEAT-Schleife zu ersetzen. Gott sei Dank spuckt mir das NDT nur eine handvoll Stellen aus, wo dies notwendig sein wird. Das hätte bei anderen Tabellen anders ausgesehen.
Die Verwendung des Primärschlüssels ist unkritisch, es wird automatisch der gleiche Schlüssel wie bisher auch gefunden.
Hat noch jemand einen Geistesblitz für mich, ehe ich die Objekte zerschieße ...?
Habt ihr Erfahrung mit Primärschlüsselerweiterungen? Worauf muss ich ggf. achten? Vielleicht besonders im Zusammenhang mit SQL-Datenbanken?
Getan habe ich folgendes: Im NDT abfragen, wo auf diese Tabelle ein GET, FINDFIRST, FINDLAST angewendet wird. Insbesondere das GET ist dann um ein FINDSET mit anschließender REPEAT-Schleife zu ersetzen. Gott sei Dank spuckt mir das NDT nur eine handvoll Stellen aus, wo dies notwendig sein wird. Das hätte bei anderen Tabellen anders ausgesehen.
Die Verwendung des Primärschlüssels ist unkritisch, es wird automatisch der gleiche Schlüssel wie bisher auch gefunden.
Hat noch jemand einen Geistesblitz für mich, ehe ich die Objekte zerschieße ...?
15. August 2007 07:08
Abgesehen vom GET das ich, sofern möglich, nur erweitern aber nicht ersetzen würde ist eine solche Änderung, wenn man alle Stellen erwischt, eher unproblematisch. Das war bei mir zumindest immer so.
Auch auf dem SQL Server sind keine Merkwürdigkeiten zu erwarten. Wenn du den PK nur erweiterst und nicht unbedingt ein Feld mitten rein setzt. Dann müsstest du die Logik ggf. genauer betrachten und die Sortierreihenfolgen und hier evtl. Code umstellen.
Auch auf dem SQL Server sind keine Merkwürdigkeiten zu erwarten. Wenn du den PK nur erweiterst und nicht unbedingt ein Feld mitten rein setzt. Dann müsstest du die Logik ggf. genauer betrachten und die Sortierreihenfolgen und hier evtl. Code umstellen.
15. August 2007 08:45
SilverX hat geschrieben:Abgesehen vom GET das ich, sofern möglich, nur erweitern aber nicht ersetzen würde
Wieso denn das?
Der Aufruf ist immer nach dem Schema
Record.GET(x,y,z);
Mach was mit Record
Nun aber gibt es nicht einen, sondern mehrere Records, bei denen die (bisherigen!) Primärschlüsselfelder identisch gefüllt sind - folglich, so glaube ich, muss ich alle betreffenden Datensätze in der Schleife durchlaufen und für alle (auch wenn es meist im Endeffekt nur einen Datensatz geben sollte) die Folgeprozeduren durchlaufen.
Und wie soll ich das Get erweitern, wenn ich gar nicht weiß, welchen Wert mein letztes, neues Primärschlüsselfeld haben soll? Dort WO ich es weiß, habe ich es dann tatsächlich bei dem GET + Erweiterung belassen.
Beim Rest glaube ich nicht, um ein FINDSET herumzukommen.
Ich hatte gestern Abend noch mit der Bearbeitung der GETs begonnen und war wirklich erstaunt bzw. froh, dass es nur 7 Objekte gab, wo diese Korrekturen notwendig waren...
15. August 2007 08:48
hast du auch geprüft, wo die Felder des PK zur Filterung bei Flowfields verwendet werden? bei einem Sum ist das ja noch egal, aber bei Lookup?
15. August 2007 08:50
Guter Einwand, ich schau mal ...
15. August 2007 08:55
Natalie hat geschrieben:SilverX hat geschrieben:Abgesehen vom GET das ich, sofern möglich, nur erweitern aber nicht ersetzen würde
Wieso denn das?
Der Aufruf ist immer nach dem Schema
Record.GET(x,y,z);
Mach was mit Record
Nun aber gibt es nicht einen, sondern mehrere Records, bei denen die (bisherigen!) Primärschlüsselfelder identisch gefüllt sind - folglich, so glaube ich, muss ich alle betreffenden Datensätze in der Schleife durchlaufen und für alle (auch wenn es meist im Endeffekt nur einen Datensatz geben sollte) die Folgeprozeduren durchlaufen.
Wie ich schrieb: "sofern möglich"
GET ist immer noch ein wenig schneller als FINDSET.
15. August 2007 09:08
SilverX hat geschrieben:Wie ich schrieb: "sofern möglich"
*Argh* Sorry, bin noch nicht wirklich wach ....
15. August 2007 09:13
Natalie hat geschrieben:Guter Einwand, ich schau mal ...
Negativ. Wird nicht verwendet. Hätte mich auch gewundert: Tabelle 5765 ist eine Tabelle ohne SumIndexFields und kann vom Benutzer nur über den Object Designer betrachtet werden, hat also nicht mal eine Form.
Mein Glück
