Zweiter versuch RIO vs Tokyo TStringDynArray

[QuickAndDirty]

Also ich den Post vorher abgeschickt hatte, war ich grundlos wieder ausgeloggt und nach dem einloggen kam der Post nicht durch. Alles geschriebene war verloren.... deswegen jetzt nur kurz...um noch so ein Disaster zu vermeiden.

- Muss die niedrigen Android Versionen mit Tokyo-Kompilaten und die hohen Android Versionen mit RIO-Kompilaten versorgen!
- Benutzte nur einen Webservice für beide Kompilate der selben APP.
- System.Types.TStringDynArray wird oft im Webservice Interfaceteil exportiert
- TMylist = Array of TMyRemotable wird oft im Webservice Interfaceteil exportiert
- TMylist = Array of TMyRemotable wird normal im im WebserviceClient abgebildet.

-In Rio gibt es System.Types.TStringDynArray nicht.
-Codegenerierung erzeugt einen Webservice Client mit TArray<String> anstatt mit TStringDynArray oder array of String
-Wenn ich in RIO Strg+linkclick im Serverinterface auf TStringDynArray klicke dann führt mich das zu

Delphi-Quellcode:

unit System.Types
[...]
type
  TArray<T> = array of T;

-Wenn ich in TOKYO Strg+linkclick in der APP auf TStringDynArray klicke dann führt mich das zu

Delphi-Quellcode:

unit System.Types
[...]
type
  TStringDynArray  = array of String;

Der durch RIO generierte Webservice Client ist natürlich inkompatibel mit Tokyo
Da in der ganzen App TStringDynarray verwendet wird und Tokyo TStringDynArray nicht kompatibel zu TArray<String> interpretiert :(

Warum diese Änderung?
Wo ist der Ausweg?

Embarcadero warum diese Fake DynArrays?
Sad.
How to make DynArrays great again?

Wieso versteht RIO überhaupt was TStringDynArray ist? Ist das kompiler magic? Weil der Bezeichner kommt ja nirgends mehr in der System.types.pas vor.

[Rollo62]

Also bei mit ist

Delphi-Quellcode:

...
  TSingleDynArray       = TArray<Single>;
  {$EXTERNALSYM TSingleDynArray 'System::TSingleDynArray'}
  TDoubleDynArray       = TArray<Double>;
  {$EXTERNALSYM TDoubleDynArray 'System::TDoubleDynArray'}
  TBooleanDynArray      = TArray<Boolean>;
  {$EXTERNALSYM TBooleanDynArray 'System::TBooleanDynArray'}
  TStringDynArray       = TArray<string>;
  {$EXTERNALSYM TStringDynArray 'System::TStringDynArray'}

in den System.Types unter Rio 10.3.1 Enterprise drin.

Edit:
Ok, ich sehe gerade Professional / Enterprise, evtl. ist da der Unterschied.

[QuickAndDirty]

Wow,
also kann es sein das
Delphi Tokyo Professional Typen hat die man in
Delphi Rio Professional nicht bekommt?

Quasi um einen in das Enterprise Abo zu "motivieren"?

Aber selbst dann

Delphi-Quellcode:

TStringDynArray = TArray<string>;

Delphi-Quellcode:

TStringDynArray = array of String;

Wäre doch immernoch nicht kompatibel.

[Whookie]

Also mein RIO Pro kennt das auch...

Delphi-Quellcode:

  TSingleDynArray       = TArray<Single>;
  {$EXTERNALSYM TSingleDynArray 'System::TSingleDynArray'}
  TDoubleDynArray       = TArray<Double>;
  {$EXTERNALSYM TDoubleDynArray 'System::TDoubleDynArray'}
  TBooleanDynArray      = TArray<Boolean>;
  {$EXTERNALSYM TBooleanDynArray 'System::TBooleanDynArray'}
  TStringDynArray       = TArray<string>;
  {$EXTERNALSYM TStringDynArray 'System::TStringDynArray'}

[GPRSNerd]

Kann ich sogar von der Rio Community Edition bestätigen (System.Types.pas):

TStringDynArray = TArray<string>;

Da ist wohl irgendwas anderes das Problem...

[Stevie]

Seit der Einführung von

Delphi-Quellcode:

TArray<T>

hab es immer wieder das Problem, dass ein

Delphi-Quellcode:

TArray<string>

nicht kompatibel war zu

Delphi-Quellcode:

TStringDynArray

, welches historisch in der RTL verwendet wurde, wenn array von string übergeben oder zurückgegeben wurde.

Daher hat man sich schon lange gewünscht (siehe RSP-16737), dass das angeglichen wird - nun endlich die Änderung in 10.3.

Die Deklaration

Delphi-Quellcode:

TStringDynArray = TArray<string>

ist nur ein Typalias im Gegensatz zu der vorherigen Deklaration, wo es ein neuer eigener Typ war (und nein,

Delphi-Quellcode:

TStringDynArray = type TArray<string>

geht nicht).

Welche Implikationen dies nun auf die Kompatibilität von Anwendungen vor und nach 10.3 hat, wurde scheinbar übersehen (war mir auch nicht klar - ich mach nix mit dem eingebauten Webservice Zeugs).

Mir ist nur gerade nicht klar, an welcher Stelle die beiden Versionen nicht kompatibel sind - in der Beschreibung der Webservice Schnittstelle nach außen? Das könnte sich durchaus fixen lassen, indem 10.3 dann erkennt, was es mit einem TStringDynArray oder wie auch immer es nach außen spezifiziert ist, anstellen soll).

Kannst du evtl ein Demoproject erstellen, um den Fehler darzustellen? Lässt sich dann auch gut als Bug bei Embarcadero reporten.

[QuickAndDirty]

Zitat:

Zitat von Stevie (Beitrag 1429212)

Kannst du evtl ein Demoproject erstellen, um den Fehler darzustellen? Lässt sich dann auch gut als Bug bei Embarcadero reporten.

Ich kann meist kein Bug reports in QC machen, weil das alles über meinen Chef gehen müsste.

Zitat:

Zitat von Stevie (Beitrag 1429212)

Mir ist nur gerade nicht klar, an welcher Stelle die beiden Versionen nicht kompatibel sind - in der Beschreibung der Webservice Schnittstelle nach außen? Das könnte sich durchaus fixen lassen, indem 10.3 dann erkennt, was es mit einem TStringDynArray oder wie auch immer es nach außen spezifiziert ist, anstellen soll).

Ich kann es mit einem Muster code verdeutlichen, so das dass problem auch ohne ein Projekt in der IDE zu öffnen deutlich wird.

Ausschnitt Interface unit des Webservice also Also Serverseitig

WebserviceIntf.pas

Delphi-Quellcode:

[...]
type

  TAnswer= Class(TRemotable)
  private
    fsuccess: boolean;
    fError: String;
  published
    property Error:String read fError write FError;       // Fehlermeldung, in der regel eine Exception
    property Success:boolean read fsuccess write fsuccess;// nur false wenn Error angezeigt werden muss
  End;

  TResponseDevicePersonRelation = Class(TAnswer)
  private
    FDevices:  TStringDynArray;
    FResource: TIntegerDynArray;
    FGroups:   TBooleanDynArray;
  public

  published
    property Devices:  TStringDynArray read fDevices write fDevices;    //Handy
    property Resource: TIntegerDynArray read fResource write fResource; //RessourcenID
    property Groups:   TBooleanDynArray read fGroups write fGroups;     //Ist Ressource eine Gruppe
  End;
[...]

Diese Klasse TResponseDevicePersonRelation wird als SOAP envelope bei einer SOAP abfrage durch den Client erzeugt....
Der Webservice erzeugt eine WSDL datei aus der sich eine dieser Delphicode wieder kompatibel erzeugen lässt!
SO SOLLTE ES SEIN!
Es galt immer für Delphi um Listen unter SOAP ordentlich abszubilden zu können müsste man DYNARRAY typen nehmen oder selber Tstrings oder TList<Tobject> serialisieren und deserialisieren.
Natürlich macht man nicht SOAP um selbst den Transport und das serialisieren programmieren zu müssen.
Also DYNARRAY

WebserviceClient.pas generiert aus WSDL datei vor Umstellung auf RIO

Delphi-Quellcode:

  TResponseDevicePersonRelation = class(TAnswer)
  private
    FDevices: TStringDynArray;
    FResource: TIntegerDynArray;
    FGroups: TBooleanDynArray;
  published
    property Devices:  TStringDynArray   read FDevices write FDevices;
    property Resource: TIntegerDynArray  read FResource write FResource;
    property Groups:   TBooleanDynArray  read FGroups write FGroups;
  end;

WebserviceClient.pas generiert aus WSDL datei nach Umstellung auf RIO

Delphi-Quellcode:

  TResponseDevicePersonRelation = class(TAnswer)
    FDevices: TArray<System.string>;
    FResource: TArray<System.Integer>;
    FGroups: TArray<System.Boolean>;
  published
    property Devices:  TArray<System.string>   read FDevices write FDevices;
    property Resource: TArray<System.Integer>  read FResource write FResource;
    property Groups:   TArray<System.Boolean>  read FGroups write FGroups;
  end;

Verwendung der klasse in der APP: Dieser Code ist nicht mehr in Tokyo compilierbar

Delphi-Quellcode:

Procedure Demo;
  function IndexOfDevice(Devices:TStringDynArray):integer
  Begin
    //bla
  end; 
  var aResponseDevicePersonRelation:TResponseDevicePersonRelation 
Begin 
  aResponseDevicePersonRelation := WebserviceClient.Request_DevicePersonRelation(a,b,c);
  myindex := IndexOfDevice(aResponseDevicePersonRelation.Devices);//<------DAS HIER KANN IN RIO KOMPILIERT WERDEN ABER IN TOKYO NICHT
end;

"DAS HIER KANN IN RIO KOMPILIERT WERDEN ABER IN TOKYO NICHT"
weil TStringDynArray in RIO ist

Code:

TStringDynArray = TARRAY<String>;

aber in Berlin ist es

Code:

TStringDynArray = array of String;

Und das mag der compiler nicht.

[TiGü]

Wird denn der "Webservice Interfaceteil", also die Pascal-Unit, die aus der WSDL entstanden ist, denn auch immer mit (neu) kompiliert? In beiden IDE-Versionen / Projekten?

[QuickAndDirty]

Zitat:

Zitat von TiGü (Beitrag 1429215)

Wird denn der "Webservice Interfaceteil", also die Pascal-Unit, die aus der WSDL entstanden ist, denn auch immer mit (neu) kompiliert? In beiden IDE-Versionen / Projekten?

Der Webservice interfaceteil wird nur in RIO kompiliert . Also der auf seiten des Servers!
Der Client Webservice Interfaceteil wird sowohl in RIO als auch in TOKYO kompiliert, weil ich die APP ja builden muss!
Die Code Generierung für den Client machen ich mit RIO weil der Server ja auch mit einem RIO Kompilat läuft.

[TiGü]

Aha, du hast erneut die WSDL importiert und der Importvorgang ersetzt den TStringDynArray-Alias mit dem dahinter liegenden Typen (TArray<string>) beim Import.
Unschön, aber nachvollziehbar. Ggf. kann man das mit einen der unzähligen Einstellmöglichkeiten des WSDL-Imports steuern.

Aber warum importierst du neu?
Es würde doch ausreichen WebserviceClient.pas nur einmalig zu importieren (in Berlin oder Tokyo) und diese Unit auch in dem Projekt zu verwenden, das mit Rio gebuildet wird. So dass die Aliase erhalten bleiben.
Dann sollte dein Problem auch verschwinden.

[QuickAndDirty]

Ich importiere die ja auch nur einmal für beide compilate!
Leider will Tokyo den Import nicht von RIO nicht! Und er passt ja auch offensichtlich nicht!
Es sei denn ich stelle in diesem seit XE8 gewachsenen sehr umfangreichen projekt alle verwendung von DYNARRAYs und WEBSERVICE aufrufe um.

Das Problem ist nicht eine code stelle wo ich ein DYNARRAY übergebe sondern das ich das eben extensiv nutze..


Ich habe zuletzt neu importiert, weil in RIO TXSDatetime einen bug hat und den Client crashed wenn man TXSDatetime.AsDatetime := 0.0 schreibt.
Habe also neue Funktionen eingebuat die Datetime als iso8061 transportieren....

Außerdem entwickle ich den Webservice und die App immer weiter und muss immer wieder neu importieren...

So importiere.
Import Script für batch file

Code:

c:
cd c:\myproject\MYSCLIENT
powershell.exe -Command "(new-object System.Net.WebClient).DownloadFile('http://myapp.mycompany.com:1234/wsdl/IMyWebService','IMyWebServiceClient.xml') "
Pause
c:
CD C:\Program Files (x86)\Embarcadero\Studio\20.0\bin
WSDLIMP -P -Ov+ -Oz- -DC:\myproject\MYSCLIENT C:\myproject\MYSCLIENT\IMyWebServiceClient.xml
Pause

Ich brauche aber vermutlich eine lösung für den EXPORT...

Diese inkompatible Umstellung der Typen ist für mich echt nicht schön....
Vielleicht hilft es eine eigene System.types zu verwenden... vorrausgesetz Embarcadero hat seine eigenen bibliotheken nicht auch umgestellt und ist jetzt auf diesen geänderten Typ angewiesen...

[TiGü]

Zitat:

Leider will Tokyo den Import nicht von RIO nicht! Und er passt ja auch offensichtlich nicht!

Dreh das mal um, dann wird alles gut!
In Tokyo importieren, die Aliase bleiben erhalten und kann in Rio-Projekt verwendet werden.

[TiGü]

Hat jetzt nur sekundär mit deinen Problem zu tun, aber vielleicht hilft es den einen oder anderen interessierten Leser bei ähnlichen Problemen:

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

{$R *.res}

type
  TMyLittleStringArray1 = array of string;
  TMyLittleStringArray2 = TArray<string>;
  TMyLittleStringArray3 = TArray<string>;
  TMyLittleStringArray4 = TMyLittleStringArray1;
  TMyLittleStringArray5 = type TMyLittleStringArray1;
  TMyLittleStringArray6 = array of string;

var
  One: TMyLittleStringArray1;
  Two: TMyLittleStringArray2;
  Three: TMyLittleStringArray3;
  Four: TMyLittleStringArray4;
  Five: TMyLittleStringArray5;
  Six: TMyLittleStringArray6;
begin
//  One := Two; // [dcc32 Error] Project1.dpr(19): E2010 Incompatible types: 'TMyLittleStringArray1' and 'System.TArray<System.string>'
//  Two := One; // [dcc32 Error] Project1.dpr(20): E2010 Incompatible types: 'System.TArray<System.string>' and 'TMyLittleStringArray1'
  One := TMyLittleStringArray1(Two); // geht durch casten
  Two := TMyLittleStringArray2(One); // geht durch casten
  Three := Two; // geht, weil beide Typen nur ein Alias sind für TArray<string>
  Two := Three; // geht, weil beide Typen nur ein Alias sind für TArray<string>
  One := Four; // geht, weil nur Alias und sonst gleicher Typ
//  Five := One; // geht nicht, da durch type Schlüsselwort ein neuer Typ gebildet wird
//  One := Six; // geht auch nicht, weil neuer Typ -> ja, auch wenn bei beiden = array of string steht
end.

[QuickAndDirty]

Je nach dem ob das Problem beim erstellen oder beim importieren der WSDL Datei passiert.

Das ganze stimmt mich alles etwas traurig...

[TiGü]

Zitat:

Zitat von QuickAndDirty (Beitrag 1429229)

Je nach dem ob das Problem beim erstellen oder beim importieren der WSDL Datei passiert.

Das ganze stimmt mich alles etwas traurig...

:wiejetzt:

Die Pascal-Unit für den Client wird doch DURCH das importieren erst erstellt!?

Du musst einfach für alle Projekte (egal ob Delphi 7, 2009, Berlin, Tokyo, Rio oder Buxtehude am Ende kompiliert und gebaut) diejenige importierte Client-Unit nehmen, die noch die TXXXDynArray-Aliase für die Member und Properties deiner SOAP-Objekte hat.
Dann ist alles gut und es gibt kein Problem.

[QuickAndDirty]

Zitat:

Zitat von TiGü (Beitrag 1429227)

Hat jetzt nur sekundär mit deinen Problem zu tun, aber vielleicht hilft es den einen oder anderen interessierten Leser bei ähnlichen Problemen:

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

{$R *.res}

type
  TMyLittleStringArray1 = array of string;
  TMyLittleStringArray2 = TArray<string>;
  TMyLittleStringArray3 = TArray<string>;
  TMyLittleStringArray4 = TMyLittleStringArray1;
  TMyLittleStringArray5 = type TMyLittleStringArray1;
  TMyLittleStringArray6 = array of string;

var
  One: TMyLittleStringArray1;
  Two: TMyLittleStringArray2;
  Three: TMyLittleStringArray3;
  Four: TMyLittleStringArray4;
  Five: TMyLittleStringArray5;
  Six: TMyLittleStringArray6;
begin
//  One := Two; // [dcc32 Error] Project1.dpr(19): E2010 Incompatible types: 'TMyLittleStringArray1' and 'System.TArray<System.string>'
//  Two := One; // [dcc32 Error] Project1.dpr(20): E2010 Incompatible types: 'System.TArray<System.string>' and 'TMyLittleStringArray1'
  One := TMyLittleStringArray1(Two); // geht durch casten
  Two := TMyLittleStringArray2(One); // geht durch casten
  Three := Two; // geht, weil beide Typen nur ein Alias sind für TArray<string>
  Two := Three; // geht, weil beide Typen nur ein Alias sind für TArray<string>
  One := Four; // geht, weil nur Alias und sonst gleicher Typ
//  Five := One; // geht nicht, da durch type Schlüsselwort ein neuer Typ gebildet wird
//  One := Six; // geht auch nicht, weil neuer Typ -> ja, auch wenn bei beiden = array of string steht
end.

Sowas ist wieder ein klassischer Fall von Irrsin der einen Ducktyping vermissen lässt oder?
Gerade beim bilden der SOAP Schnittstelle...

[TiGü]

Zitat:

Zitat von QuickAndDirty (Beitrag 1429237)

Sowas ist wieder ein klassischer Fall von Irrsin der einen Ducktyping vermissen lässt oder?
Gerade beim bilden der SOAP Schnittstelle...

Nein, denn damit (also aufgrund von dynamischen Typensystem) hat man dann wieder anderen Irrsinn.

Aber hast du denn jetzt meinen Rat umgesetzt?
Mit der Verwendung der Tokyo-Unit im Rio-Projekt (und nicht umgekehrt) sollten ja alle deine Probleme verschwinden.

[QuickAndDirty]

Ja das Problem ist schon in der WSDL datei.
Da der Webservice ein RIO Kompilat ist gibt er eine WSDL Datei aus die auch TOKYO veranlasst eine TARRAY<String> als Typen in der Client datei zu verwenden.

Der Umstieg von TOKYO -> RIO hat quasi implizit das Komplette Interface zu dem Webservice zu neuen Typen portiert....
kaum zu fassen...

Webservice kompiliert mit Tokyo: WSDL datei

Code:

      <xs:complexType name="TResponseDevicePersonRelation">
        <xs:complexContent>
          <xs:extension base="ns1:TAnswer">
            <sequence xmlns="http://www.w3.org/2001/XMLSchema">
              <xs:element name="Devices" type="ns2:TStringDynArray"/>
              <xs:element name="Resource" type="ns2:TIntegerDynArray"/>
              <xs:element name="Groups" type="ns2:TBooleanDynArray"/>
            </sequence>
          </xs:extension>
        </xs:complexContent>
      </xs:complexType>

Webservice kompiliert mit RIO: WSDL datei

Code:

      <xs:complexType name="TResponseDevicePersonRelation">
        <xs:complexContent>
          <xs:extension base="ns1:TAnswer">
            <sequence xmlns="http://www.w3.org/2001/XMLSchema">
              <xs:element name="Devices" type="ns2:TArray&lt;System.string&gt;"/>
              <xs:element name="Resource" type="ns2:TArray&lt;System.Integer&gt;"/>
              <xs:element name="Groups" type="ns2:TArray&lt;System.Boolean&gt;"/>
            </sequence>
          </xs:extension>
        </xs:complexContent>
      </xs:complexType>

[Schokohase]

[OT]Internet ist Neuland[/OT]

[QuickAndDirty]

Zitat:

Zitat von Schokohase (Beitrag 1429251)

[OT]Internet ist Neuland[/OT]

Bitte lösen. Wo ist der Link ?
Meinst du den hier?
https://en.delphipraxis.net/topic/52...ponse-problem/
Der soviel sagt wie : Mach bloß nichts mit RIO und HTTP , das ist komplett recoded und zerstört?

[TiGü]

Vielleicht wäre es besser, die Definition der Arraytypen selber zu machen und sich nicht auf die Definitionen in System.Types zu verlassen.
So ist das auch schwierig, die WSDL in andere Sprachen zu importieren (bzw. man müsste man es mal prüfen, was damit gemacht wird).

[QuickAndDirty]

Zitat:

Zitat von TiGü (Beitrag 1429256)

Vielleicht wäre es besser, die Definition der Arraytypen selber zu machen und sich nicht auf die Definitionen in System.Types zu verlassen.
So ist das auch schwierig, die WSDL in andere Sprachen zu importieren (bzw. man müsste man es mal prüfen, was damit gemacht wird).

Ich werde jetzt tatsächlich die definitionen local überschreiben, so dass wenigstens die WSDL Datei eine Form hat die ich erwarte.
:(
Es scheint einen haufen converter optionen zu geben aber keine davon hat die gewünschte Auswirkung ,die Aliase nicht zu interpretieren...

Auf dem WebServiceModule

HTTPSoapPascalInvoker1.Converter.options

soDontSendVarArrayType...macht nichts
soLiteralParams...macht nichts

[QuickAndDirty]

Hab die Definitionen von Tokyo in meine CommonTypes unit kopiert.... und diese in der Interface definition von dem Webservice aufgenommen.
Somit wird die WSDL datei schon mal ordentlich erzeugt... und in der Geschäftlogik ist die unit eh schon überall referenziert!

Gucken wir mal wie die verschiedenen Clients in den Verschiedenen Versionen zu handhaben sind....

[QuickAndDirty]

Wow...
also Wenn ich diese Typen in einer eigenen UNIT deklariere und diese benutze exportiert der WEBSERVICE sie über die WSDL datei und sie werden dann in der generierten Clientdatei mit angelegt....
also wären sie 2 mal deklariert einmal in meiner allgemeinen Typen unit und einem in der generierten client unit...
und das 2 verschiedene typen sind

TYP1 = array of String
TYP2 = array of String

geht das so nicht....

:(

meine fresse Embarcadero....

Also muss ich jetzt groß umbauen :(

[TiGü]

Zitat:

Zitat von QuickAndDirty (Beitrag 1429265)

Wow...
also Wenn ich diese Typen in einer eigenen UNIT deklariere und diese benutze exportiert der WEBSERVICE sie über die WSDL datei und sie werden dann in der generierten Clientdatei mit angelegt....
also wären sie 2 mal deklariert einmal in meiner allgemeinen Typen unit und einem in der generierten client unit...
und das 2 verschiedene typen sind

TYP1 = array of String
TYP2 = array of String

geht das so nicht....

:(

meine fresse Embarcadero....

Also muss ich jetzt groß umbauen :(

Les nochmal Beitrag #21.
Es ist schon ganz richtig so, dass die Typdefinitionen in die WSDL konvertiert werden.
Wie sollen sonst andere Importer die Typen in Java, C#, C++ abbilden? Denen steht System.Types oder deine Common-Unit nicht zur Verfügung.
Es ist vielleicht einfach eine Verständnisschwierigkeit auf deiner Seite?

[QuickAndDirty]

Nein mir ist das klar.
Aber das er eben vorher in Tokyo beim import erkannt das er diese Definitionen bereits hat, weil sie eben aus System.types stammen.
Mit eigenen definitionen läuft das natürlich nicht...
Also habe ich jetzt alles, wirklich alles. auf TArray<Einfachertyp> umgestellt...
Der Quellcode läuft in Beiden in RIO und Tokyo sowohl am Server sowie auf den 3 verschienden Client Apps und Anwendungen.


[OT]
Wieder eine Menge Zeit zur Verbesserung der Anwendungen für die User sinnvoll eingesetzt.
Sorry wegen des rumheulens. Ist gerade kein guter Moment.
[/OT]

[TiGü]

Zitat:

Zitat von QuickAndDirty (Beitrag 1429435)

[OT]
Wieder eine Menge Zeit zur Verbesserung der Anwendungen für die User sinnvoll eingesetzt.
Sorry wegen des rumheulens. Ist gerade kein guter Moment.
[/OT]

Kenn ich...das ist einer dieser "Hätte ich es nur von Anfang an richtig gemacht"-Momente.
Nervt und ist zeitraubend, aber zumindest konnte man das Problem lösen.