[Gelöst] Wie ändert man die Optionen-Reihenfolge?
23. Oktober 2007 09:47
Hallo Allerseits,
das kommt davon, wenn man erst handelt und dann nachdenkt...
Ich hab eine Tabelle mit einem Optionenfeld, daß mir dann in der Businesslogik eine ganze Menge steuert, d.h. über CASE läuft das Progrämmle in verschiedene Zweige.
Nun halte ich es für zweckmäßig, die Reihenfolge der Optionen zu ändern.
Wie kann ich das effizient bewerkstellen, ohne mir den Code zerschiessen?
Viele Grüße,
SF
das kommt davon, wenn man erst handelt und dann nachdenkt...
Ich hab eine Tabelle mit einem Optionenfeld, daß mir dann in der Businesslogik eine ganze Menge steuert, d.h. über CASE läuft das Progrämmle in verschiedene Zweige.
Nun halte ich es für zweckmäßig, die Reihenfolge der Optionen zu ändern.
Wie kann ich das effizient bewerkstellen, ohne mir den Code zerschiessen?
Viele Grüße,
SF
Zuletzt geändert von SafetyFirst am 24. Oktober 2007 09:52, insgesamt 1-mal geändert.
23. Oktober 2007 10:32
Der CASE-Anweisung ist die Reihenfolge der Optionswerte egal (ganz im Gegensatz zu höheren Programmiersprachen). Falls du deine Anweisung also in der Form
formuliert hast, brauchst du nichts zu ändern (sonst tu das in genau dieser Form).
Was viel problematischer ist, sind vorhandene Datensätze in der Datenbank. Gibt es sie, musst du einen Report schreiben, der die Optionswerte konvertiert.
- Code:
CASE Option OF
Option::Optionswert1 : mache was ;
Option::Optionswert2 : mache was anderes;
END;
formuliert hast, brauchst du nichts zu ändern (sonst tu das in genau dieser Form).
Was viel problematischer ist, sind vorhandene Datensätze in der Datenbank. Gibt es sie, musst du einen Report schreiben, der die Optionswerte konvertiert.
23. Oktober 2007 10:46
Es gibt da schon ein Problem, weil in allen kompilierten Objekten, die dieses Feld verwenden, die Optionswerte im Code mit getauscht werden. Das kann man verhindern, in dem man diese Objekte in einen unkompilierten Zustand versetzt, dann die Reihenfolge ändert, und diese dann neu kompiliert.
Die Fälle, wo diese Optionen eventuell als Integerwert ( z.b. Funktionsparameter) verwendet werden, muss man allerdings zusätzlich prüfen.
Die Fälle, wo diese Optionen eventuell als Integerwert ( z.b. Funktionsparameter) verwendet werden, muss man allerdings zusätzlich prüfen.
23. Oktober 2007 11:37
Hallo SafetyFirst, hallo zusammen,
Ist nun keine direkte Lösung für Dein Problem, aber vielleicht hilfts ja zukünftig sowas zu vermeiden.
Du kannst wenn Du einen OptionString anlegst Platzhalter schaffen:
OptionString = 0,1,,,4
die 2 und 3 die Du nich siehst, werden Dir nirgens angezeigt, niemand wird sie befüllen können, aber der Developer kann irgendwann mal neue Positionen dazwischen quetschen.
Wenn ich Dein Problem richtig verstanden hab, dann wirst Du nicht umhin kommen, eine weitere Option anzufügen um sie als Auslagerungsplatz zu missbrauchen damit Du alle Werte via Report umändern kannst.
Dann hast Du nur noch das Problem mit dem Code...
Ist nun keine direkte Lösung für Dein Problem, aber vielleicht hilfts ja zukünftig sowas zu vermeiden.
Du kannst wenn Du einen OptionString anlegst Platzhalter schaffen:
OptionString = 0,1,,,4
die 2 und 3 die Du nich siehst, werden Dir nirgens angezeigt, niemand wird sie befüllen können, aber der Developer kann irgendwann mal neue Positionen dazwischen quetschen.
Wenn ich Dein Problem richtig verstanden hab, dann wirst Du nicht umhin kommen, eine weitere Option anzufügen um sie als Auslagerungsplatz zu missbrauchen damit Du alle Werte via Report umändern kannst.
Dann hast Du nur noch das Problem mit dem Code...
23. Oktober 2007 12:08
Rick hat geschrieben:Du kannst wenn Du einen OptionString anlegst Platzhalter schaffen:
Diese Platzhalter ( mind. 10) sind unbedingt Pflicht, wenn Optionsfelder aus dem Standard erweitert werden. Nie einfach neue Optionswerte anhängen, wenn der Standard dann in neuen Versionen ggf. erweitert wird, steht man vor erheblichem Aufwand um den Code zu überarbeiten.
24. Oktober 2007 08:37
Hallo Allerseits,
das sind ja super Antworten!
Natalie,
in der Tat habe ich konsequent mit CASE-Anweisungen codiert, wie von Dir beschrieben. Zwischenzeitlich hatte ich dann schon mal einen Optionswert in einer Regeltabelle eingeschoben und bekam dann den Effekt, daß die nachfolgenden Optionenwerte "verrutscht" waren, genau wie es Kowa beschreibt.
Kowa, ich werde es so probieren, wie Du es sagst. Ich nehme an, es reicht, wenn ich eine kleine Codeänderung vornehme und dan die CU unkompiliert speichere, oder?
Mit Integers arbeite ich hier nicht, sondern habe immer diese "properly nested" Syntax verwendet (oder wie man das nennt).
Hochinteressant ist der Tipp mit den Leerwerten. Sind hier mit "Standard" die zertifizierten Programmteile gemeint? Bedeutet dies, wenn ich den Standard kundenspezifisch erweitern will, dann erstmal 10 Leerstellen schaffen, bevor ich mit meinen eigenen Optionen ankomme? Das klingt clever. Ist das so eine Art ungeschriebenes Gesetz im Allgemeinen, oder ein guter Tipp von Dir im speziellen? (Bin ja bemüht, "anständig" zu codieren) . Werde den Rat jedenfalls beherzigen.
Vielen Dank nochmal für die tollen Antworten!
Viele Grüße,
SF
das sind ja super Antworten!
Natalie,
in der Tat habe ich konsequent mit CASE-Anweisungen codiert, wie von Dir beschrieben. Zwischenzeitlich hatte ich dann schon mal einen Optionswert in einer Regeltabelle eingeschoben und bekam dann den Effekt, daß die nachfolgenden Optionenwerte "verrutscht" waren, genau wie es Kowa beschreibt.
Kowa, ich werde es so probieren, wie Du es sagst. Ich nehme an, es reicht, wenn ich eine kleine Codeänderung vornehme und dan die CU unkompiliert speichere, oder?
Mit Integers arbeite ich hier nicht, sondern habe immer diese "properly nested" Syntax verwendet (oder wie man das nennt).
Hochinteressant ist der Tipp mit den Leerwerten. Sind hier mit "Standard" die zertifizierten Programmteile gemeint? Bedeutet dies, wenn ich den Standard kundenspezifisch erweitern will, dann erstmal 10 Leerstellen schaffen, bevor ich mit meinen eigenen Optionen ankomme? Das klingt clever. Ist das so eine Art ungeschriebenes Gesetz im Allgemeinen, oder ein guter Tipp von Dir im speziellen? (Bin ja bemüht, "anständig" zu codieren) . Werde den Rat jedenfalls beherzigen.
Vielen Dank nochmal für die tollen Antworten!
Viele Grüße,
SF
24. Oktober 2007 09:35
Hallo,
Update: Mit der von Kowa empfohlenen Methode klappt's!
Vielen Dank!
:)
SF
Update: Mit der von Kowa empfohlenen Methode klappt's!
Vielen Dank!
:)
SF
24. Oktober 2007 13:37
SafetyFirst hat geschrieben:in der Tat habe ich konsequent mit CASE-Anweisungen codiert, wie von Dir beschrieben. Zwischenzeitlich hatte ich dann schon mal einen Optionswert in einer Regeltabelle eingeschoben und bekam dann den Effekt, daß die nachfolgenden Optionenwerte "verrutscht" waren, genau wie es Kowa beschreibt.
Argh, stimmt, das hatte ich nicht bedacht. Automatische Anpassung des Quelltextes ... naja, aus Delphi kannte ich dieses Prolbem nicht und falle immer wieder auf sowas herein *seufz*
24. Oktober 2007 13:40
Hihihi....
freut mich doch, daß nicht nur ich dem Navision immer wieder auf den Leim gehe, sondern auch Profis wie Ihr...
Liebe Grüße,
SF
freut mich doch, daß nicht nur ich dem Navision immer wieder auf den Leim gehe, sondern auch Profis wie Ihr...
Liebe Grüße,
SF
24. Oktober 2007 14:36
SafetyFirst hat geschrieben:Hochinteressant ist der Tipp mit den Leerwerten. Sind hier mit "Standard" die zertifizierten Programmteile gemeint? Bedeutet dies, wenn ich den Standard kundenspezifisch erweitern will, dann erstmal 10 Leerstellen schaffen, bevor ich mit meinen eigenen Optionen ankomme? Das klingt clever. Ist das so eine Art ungeschriebenes Gesetz im Allgemeinen, oder ein guter Tipp von Dir im speziellen? (Bin ja bemüht, "anständig" zu codieren) . Werde den Rat jedenfalls beherzigen.
Das wird in den offiziellen Programmierungskursen so gelehrt.
Ein Beispiel ist z. B das Feld "Status" im Verkaufskopf , welches in bis Version 4 zwei Optionswerte hatte ("Open, Released"). In Version 5.0 kamen dann mit der Belegauthorisierung und Anzahlung zwei weitere Optionswerte dazu. Wenn hier in der alten Version eigene Optionen einfach angehängt wurden, hat man beim Upgrade unnötige Probleme, weil diese die gleichen Integerwerte belegen wie die neuen aus dem Standard. Zusätzlich erschwerend ist, dass diese Fehler beim Kompileren nicht unbedingt gemeldet werden, der Code aber durch den Kompilierungsvorgang eben automatisch geändert wird. Die "lustigen" Effekte, die das nach sich ziehen kann, darf sich jeder selber ausmalen.
Für Optionsfelder aus Add-Ons/ Branchenlösungen gilt natürlich das gleiche. Auch diese können vom Lieferanten der Software neue Optionen erhalten. Nur selbst erstellte Optionsfeldern können von Platzhaltern verschont bleiben.
Zuletzt geändert von Kowa am 24. Oktober 2007 14:45, insgesamt 2-mal geändert.
24. Oktober 2007 14:43
Hallo Kowa,
ja - das entstehende Chaos kann ich bildlich vorstellen...
OK, ich werde dies beherzigen!
Einen "offiziellen Programmierkurs" durfte ich aus Anfänger-Niveau besuchen. Seither weiß ich wenigstens schonmal, welche Fragen ich stellen muß.
Danke Euch Allen! Ihr wart mir mal wieder eine große Hilfe!
Viele Grüße,
SF
ja - das entstehende Chaos kann ich bildlich vorstellen...
OK, ich werde dies beherzigen!
Einen "offiziellen Programmierkurs" durfte ich aus Anfänger-Niveau besuchen. Seither weiß ich wenigstens schonmal, welche Fragen ich stellen muß.
Danke Euch Allen! Ihr wart mir mal wieder eine große Hilfe!
Viele Grüße,
SF