[gelöst] Prüfen von Importdaten

In das Primärschlüsselfeld einer Setup Table schreibt man normalerweise nichts, weil dann Setup.GET nicht mehr funktioniert.

das habe ich auch nicht gesagt - aber wenn er den Pfad eingetragen hätte, wäre der Datensatz angelegt gewesen und es hätte gepasst

Guten Morgen.

sonst habt ihr am Ende nur eine zusammengefrickelte Lösung, die in keinster Weise mehr updatefähig ist.

Wieso zusammengefrickelte Lösung? Sehe ich nicht.
Ich habe die Aufgabe so bekommen und muss mich der Herausforderung stellen!
Bin übrigens über die Unterstützung, welche mir hier zu Teil geworden ist, sehr dankbar!
Ich versuche mich stets zu informieren und moderne Frameworks und Basics zu verwenden und Programme zu testen soweit es mir möglich ist.
Es gibt auch nach Fertigstellung eine Abnahme, durch einen Senior Navision Programmierer aus der Firma.

Wie gewährleiste ich außerdem die Updatefähigkeit und wie geht sie mir verloren?

Ich nehme eure Kritik ernst und versuche sie zu berücksichtigen!

Gruß, Christian

klar hast du die Anforderung bekommen und ich finde es auch gut, dass du dich da so reinhängst - also meinen Respekt hast du!
was ich meine ist, dass ihr aufpassen müsst, wie ihr welche stellen anpasst.
Also wenn du z.B. viel an Standardobjekten anpasst, dann sind die bei jedem Update zu mergen
Wenn du natürlich in deinem eigenen Objektbereich Anpassungen vornimmst, dann interessiert das beim Update garnicht (oder zumindest wenig)

Also wenn du z.B. viel an Standardobjekten anpasst, dann sind die bei jedem Update zu mergen

Gut zu wissen, aber vom Standard habe ich die Finger gelassen!
Ich habe bisher eigene Objekte verwendet.

Gruß, Christian

Das ist übrigens der Moment wo GIT um die Ecke springt und dir das Upgrade automerged.

Anmerkung:
Es ist natürlich besser gar nicht mergen zu müssen aber diese unglaubliche Angst in der NAV Welt vor Anpassungen und mergen ist sowas von übertrieben.
In der NAV Welt läuft an dieser Stelle irgendwas falsch.

Angst vor Anpassungen?
hab ich noch nie gehört.

Sicherlich funktioniert ein Automerge in vielen Fällen, aber halt nicht in allen

Ja gut, wenn automerge mal nicht klappt muss man halt wirklich mal das machen was man sonst immer zu 100% machen muss

Das folgende Zitat von Marije Brummel stellt es meiner Meinung nach gut dar.

They will never replace you, because still there are exceptions which needs some human brain to solve, but it is not 100% of the process now, but e.g. 10%.

Merge of our new version of addon to some customer database was 1-2 days in some cases.
Now, with the script support, it is just 2-3 hours, in which the 1.5-2.5 hours are automatized and only 0.5 hour is “conflict solving”.

Ich finde es gut das du die Angst vor Anpassungen nicht kennst, das kann ein Zeichen sein das bei euch die Welt in Ordnung ist.

Du musst dir vorstellen bei anderen NSCs Programmieren ganze Teams auf der selben Datenbank völlig unisoliert.
Sie Entwickeln ohne Versionskontrolle nur mit diesem Advanced Object Manager.
Du kannst keine Programmversion (bestehend aus Tausenden Einzelobjekten in der richtigen Version) wiederherstellen um mal etwas zu prüfen.
Du kannst nur pro Objekt die Historie sehen und musst per Hand alle Changes als "Projekt" zusammenhalten um mal ein Change abzubilden.
Objekte werden nicht Released als Release oder Patch mit Version sondern als einzelne Fobs ständig zwischen 3 Datenbanken gewechselt (DEV,TEST,LIVE).
Manchmal wird in der Live DB Entwickelt und die Objekte werden Zeitgleich von anderen in der DEV DB angepasst und du musst jetzt beide Seiten zurückholen, mergen und dann wieder den Prozess des auslieferns der Reihe nach von DEV->Test->Live durchziehen damit wieder alles im Lot ist.

Das ist jetzt nur was mir einfällt wenn ich nicht länger drüber nachdenke. Solche Prozesse/Tools, da hätte ich auch Angst.

Bei Bewerbungsgesprächen ist eine meiner Standardfragen welche Versionskontrolle benutzt wird.Wenn ich höre Object Manager Advanced höre ist das oben geschriebene wahrscheinlich.
Es ist nur 2x vorgekommen das die Firmen nicht OMA gesagt haben.
Ich schätze also das nur 10-20% der Unternehmen Moderne Tools und Vorgehen verwenden und das macht mir Angst.

Das ist übrigens der Moment wo GIT um die Ecke springt und dir das Upgrade automerged.

Sorry, aber das ist quatsch.
Das einzige was du für ein Automerge benötigst:
Deine Aktuelle DB und die DB im Rohzustand (am besten mit allen Addons die installiert sind)

Manchmal wird in der Live DB Entwickelt und die Objekte werden Zeitgleich von anderen in der DEV DB angepasst und du musst jetzt beide Seiten zurückholen, mergen und dann wieder den Prozess des auslieferns der Reihe nach von DEV->Test->Live durchziehen damit wieder alles im Lot ist.

Das geht mit Git genauso...
"Manchmal wird im "Master" Branch Entwickelt um schnell etwas im nächsten Deployment Prozess noch mit rein zu schieben Zeitgleich ändert jemand etwas im Dev Branch und man muss es mergen."
Es ist hier einfach ne Philosphifrage, wie die Prozesse in der Entwicklung sind und wie diese gelebt werden.


Versteh mich nicht falsch, wir nutzen auch Git aber erst seitdem wir AL in VSCode entwickeln.
Und wenn du mich nun fragst ob es Sinnvoll ist, würde ich dir die Frage mit wohl mit Ja beantworten:
Es ist genauso Sinnvoll wie nen Datenbank Backup vor nem (CU)Update. Es nervt aber wenn etwas schief geht kann man "von Vorn" anfangen. Ich persönlich musste davon noch nie gebraucht machen.

...wir nutzen auch Git aber erst seitdem wir AL in VSCode entwickeln.
Und wenn du mich nun fragst ob es Sinnvoll ist, würde ich dir die Frage mit wohl mit Ja beantworten:
Es ist genauso Sinnvoll wie nen Datenbank Backup vor nem (CU)Update. Es nervt aber wenn etwas schief geht kann man "von Vorn" anfangen.

+1
same here.
trotzdem traurig, denn ich kann nobody's Aussage total nachvollziehen