[gelöst]Upgrade BC14->BC21OnPr viele Kompilierfehler al Konv

Hallo,

Der mag bei allen 3 Feldern die Expression nicht, ich muss erst ein Rec. davor setzen.

Ich sagte doch, txt2al benutzen, und dann Datei für Datei in Projekt ziehen und überarbeiten.
Aber für das Rec. gibt es eine recht einfache Lösung:
Suchen und Ersetzen: Suche nach

Code:

;"

ersetzen durch

Code:

;Rec."

Das hilft für alle Felder, die in Anführungsstrichen stehen, was je nach Entwickler meisten sind. (bei mir erledigt das jeden falls das meiste )

Gruß Fiddi

Hallo

das auf die neuere Version stellen ist keine gute Idee, wenn du die App für BC14 schreiben willst, das kann noch nicht alles.

Gruß Fiddi

Danke Dir Fiddi,

zum zweiten Punkt:
Ziel soll eine BC21 App sein, Datenkonvertierung werde ich vermutlich am Microsoft Weg vorbei machen und dann die Daten per SQL Script kopieren.
Eigentlich ist mir für die App die BC Zielversion egal, hauptsache die Extension würde überhaupt mal laufen.

zu " txt2al benutzen, und dann Datei für Datei in Projekt ziehen und überarbeiten"
wie genau soll das denn gehen, die Pages, Tabellen,Codeunits greifen doch alle ineinander,
komplexe Tabellen Beziehungen etc. , jedes Objekt hängt doch wiederum von vielen ab oder wird von vielen verwendet.

Das mit dem Rec verstehe ich nicht.
In der Page wird doch eine Source Table angegeben, wie früher auch.
Warum muss dann jedem Control explizit das .REC hinzugefügt werden?
In einem Schlungsbuch 365 sehe ich auch den Aufbau von Pages und da wirdauch kein Rec. vorangestellt.
Kann das nicht ein Bug sein?
Bei 100 Pages wäre das eine spannende Fleißaufgabe, das kann doch fast nicht zum glauben sein,
dass der al Konverter so grottenschlecht ist?

Hallo,

In der Page wird doch eine Source Table angegeben, wie früher auch.

Es scheint einige Entwickler zu geben, die mit dem "With"- Statement auf Kriegsfuß stehen.
Durch die Extensions kann es da tatsächlich zu Problemen kommen, wenn da in unterschiedlichen Extensions Variablen oder auch Feldnamen verwendet werden, die ursprünglich mal nur Variablennamen waren, aber jetzt durch eine Extension plötzlich auch zu Feldern werden. Dann kann das schon mal merkwürdige Effekte haben.

Um das Ganze auch bei den impliziten "With" auszuschließen, sollen jetzt alle Referenzen auf Record- Variablen mit dem Variablennamen versehen werden. Bei den Feldern einer Page halt mit "Rec.".

Gruß Fiddi

danke Dir Fiddi,

verstehe.
Ich glaube Dein Hinweis mit dem WITH Zeug ist der Grund.

Ich habe in der Zwischenzeit in das heute erstellte Projekt wieder alle Dateien eingefügt.
Im Alten Projekt hatt ich knapp 500 Kompilierfehler,
im neuen dann über 20000. Hab den Grund nicht verstanden.
Das neu Projekt wurde ja über AL Go angelegt.
In der app.json wurde eine Passage hinzugefügt, die im alten Projekt nicht drin war.
Entfernt man den Teil wieder, sind es wieder knapp 500 Fehler und der Bug in der Page ist nun auch weg,
dann kennt er die Felder wieder ohne Rec. davor

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

das schöne ist, dass ich bei den knapp 500 Fehlern nun auch etliche echte Fehler finden konnte,
wo wirklich auch im BC14 Code was nicht stimmt, obwohl in BC14 dies keine Kompiler Fehler sind.
Beispiel: in etlichen Tabellen sind bei den fielgroups noch Felder, die es nicht mehr gibt.
Sowas kann ich verstehen.

Ein unschöner Fehler ist mir noch aufgefallen:
viele Optionsfelder sind bei uns so angelegt,
dass der erste Option String ein Blank/Leerzeichen ist.
Hat den Vorteil, dass Standardmäßig dieses Leerzeichen vorbelegt ist.
An vielen Stellen im Code Filtern wir z.B. ob das Feld Blank oder eben nicht Blank sein darf,
mit diesem "0" Filter, da schreit der Kompiler nun.
Das wäre wirklich übel, wenn das nicht mehr geht


was ich leider noch sehr oft habe ist das AL0197 Problem,
mit dem dass das Objekt schon existieren soll.
Das ist für mich noch der größte unlogische Fehler.
Die Links von Dir Kowa habe ich alle probiert,
an der Ecke komme ich leider keinen Meter weiter

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Es scheint einige Entwickler zu geben, die mit dem "With"- Statement auf Kriegsfuß stehen.

With war ab BC 17 auf deprecated (Explicit und Implicit)
Deprecating Explicit and Implicit With Statements
erst ab BC 21 wurde Implicit With wieder zugelassen.

Code:

"With Business Central 2022 release wave 2, the AL:Go! template for creating new AL projects in Visual Studio Code, now enables explicit with statements by default, by adding the NoImplicitWith option to the features property in the generated app.json file.

Der Code muss also entsprechend angepasst werden, alternativ ganz weglassen.

ich wollte einfach unsere komplette Lösung in reinem C/AL Code durch den AL Konverter (txt2al) jagen

Im OMA gibt es auch einen AL-Konverter. Den könnte man alternativ mal probieren.
https://www.qbsgroup.com/event/introduction-to-idyns-object-manager-advanced-oma/
Als wir noch viel für BC konvertieren mussten, wurde der bei uns viel benutzt. Mittlerweile gibt es allerdings kaum noch einen bei uns, der OMA überhaupt noch nutzt, bei der sonstigen Flut von Tools in VSC für alles Mögliche.

viele Optionsfelder sind bei uns so angelegt, dass der erste Option String ein Blank/Leerzeichen ist. Hat den Vorteil, dass Standardmäßig dieses Leerzeichen vorbelegt ist.
An vielen Stellen im Code Filtern wir z.B. ob das Feld Blank oder eben nicht Blank sein darf, mit diesem "0" Filter, da schreit der Kompiler nun.

Das umsetzen von Optionen in Txt2AL ist ein Problem. In deinem Beispiel ist es ja zu "0" geworden, aber " " wäre korrekt. (Früher wäre auch 0 korrekt gewesen ohne Anführungszeichen weil die Optionen in Wahrheit ja Integer sind von 0 beginnend gezählt. In BC ist aber der Optionsname zu verwenden. Noch besser natürlich Enum statt Option.)

Um With zu entfernen, fehlendes Rec. zu erzeugen u.v.a.
AZ/AL Dev Tools
Nur zwei von vielen hilfreichen Anweisungen.

Remove 'with' usage from the Active Editor: removes all implicit and explicit 'with' usage from the current editor
Remove 'with' usage from the Active Project: removes all implicit and explicit 'with' usage from the current project

Erwischt zwar nicht alles, aber fast alles.

sorry für meine späte antwort und vielen vielen herzlichen dank für Eure neue beiträge,
hab soweit alles verstanden

ich habe jetzt über eine woche weitergearbeitet und habe mich auf fehler konzentriert,
die ich nachvollziehen kann. Es sind einfach sehr viele Fehler, wo wirklich in der Altversion Probleme waren,
der neue BC21 Kompiler deckt diese leichter auf als der alte BC14 Kompiler: z.B. Fieldgroups mit nicht mehr existierenden Feldern,
Textkonstanten in die per copy paste irgendwelche Blanks und unicode zeichen reinkopiert wurden, usw.
Diese Bereinigungen geben wirklich sinn.

Pos. Nebeneffekt: diese seltsamen Fehler dass irgendein Objekt mit dieser ID schon vorhanden ist, scheinen massiv zu verschwinden.
Von meinen urspr. 500 Fehlern bin auch auf knapp über 100 runter und arbeite mich weiter fleissig durch.
Möchte mich bei allen für Eure tolle und tatkräftige Hilfe bedanken, die ganzen Beiträge haben mir wirklich sehr geholfen
Wünsche allen ein schönes Wochenende und Viele Grüße