Delphi 10 und Delphi 10.2.2 Fehler

[berlinchris81]

Hallo Community,

ich habe ein Datasnap Programm unter Delphi XE 10 Seattle erstellt und es funktioniert damit prima. Danach habe ich ein Update auf XE 10.1 -> XE 10.2 und nun letztendlich 10.2.2 gemacht. Leider erhalte ich jetzt beim Verbinden zum Datasnap Server die Fehlermeldung " 12032 - ERROR_INTERNET_FORCE_RETRY - der Request muss erneut gesendet werden". Kann mir jemand helfen? Ich finde keine Einstellung wo ich einen Request wiederholen bzw. die Exception abschalten kann. Ich habe die Meldung angehängt.

Wenn ich mit Version 10 kompiliere kommt keine Meldung und es läuft, mit 10.2.2 kompiliert erscheint die Fehlermeldung.

Für eure Hilfe wäre ich sehr dankbar.


Christian Müller

Anhang 48602

[lowmax_5]

Ist die midas.dll aktualisiert (von 10.2)?

[berlinchris81]

Hallo vielen Dank erstmal für die Antwort.

Ich habe damals die Unit MidasLib eingebunden, muss ich da jetzt nochmal was unter 10.2.2 importieren?

Vielen Dank für die Mühen

Chris

[lowmax_5]

Das Einbinden Unit MidasLib ist der beste Weg,um Versionsprobleme zu vermeiden

[berlinchris81]

Das ist bereits von Anfang an so, leider ist das nicht des Rätsels Lösung. Schade

[himitsu]

ERROR_INTERNET_FORCE_RETRY
Wow, der erste Treffer mit 14 Jahren immernoch so aktuell. :lol:
http://microsoft.public.inetsdk.prog...et-force-retry

https://msdn.microsoft.com/en-us/lib.../aa384220.aspx


Server und Client mit der gleichen Version kompiliert?

Tritt das immer oder nur manchmal auf?
Kann ja sein, dass sich in den Versionen die Authentifizierung etwas geändert hat und es daher sich anders verhält.

Ich denke eher es liegt nicht am MIDAS, sondern am Indy, welches ebenfalls vom DataSnap genutzt wird und wo doch bestimmt auch das WinINet genutzt wird.


Schade, dass dieser "Rückfrage" von fast Allen als "Fehler" behandelt wird, anstatt eine winzige Schleife/GOTO um die Anfrage zu implementieren.

[berlinchris81]

Ja, Server und Client sind auf der selben IDE kompiliert. Der Fehler tritt immer auf, ich habe mit 10.2.2 keine Chance mich zu verbinden.

Die Microsoftseite habe ich auch schon gefunden, konnte aber leider nichts wirklich damit anfangen. Habe mich damals langsam an Datasnap rangetastet, ohne das ich groß die Hintergründe hinterfragt habe. WinInet hatte ich auch als Fehlerquelle auf der Uhr, bin aber ratlos. Gibt es denn ne Möglichkeit diesen "request resend" mit Datasnap zu erreichen.


Vielen Dank für die Hilfe.

Chris

[himitsu]

Nee, weiß leider jetzt auch nicht wie und wo.

Wir/Ich sind auch eher daran das DataSnap wieder auszubauen. Gerade erst die eine Hälfte ausgebaut, also alles was mit Datenbank/DataSets zu tun hat und falls der Rest auch rummuckt ... gibt genügend andere Anbieter für einfaches RPC.
Wir wollten danach eigentlich auch bald auf von XE auf 10.2 umsteigen. Die ersten Tests mit 10 und 10.1 liefen gut, bis auf paar Fremdkomponenten, aber DataSnap war in dem Test noch nicht enthalten. :?

[berlinchris81]

Schade, Datasnap ausbauen wäre eine Option. Macht ne Menge arbeit, aber wenn das Arbeiten damit nicht funktioniert, dann muss es wohl sein. Ich kann ja nicht ewig einen XE 10 PC vorhalten und dieses Programm zu kompilieren.

LG

[himitsu]

Wir hatten den Vorteil, dass Postgres einen netten Materialized View eingebaut hat, der gleich beim ersten Versuch problemlos funktionierte, in unserer "gewachsenen" Anwendung.

Hatte damals paar Monate gebraucht, bis unser DataSet-Cache und die Übertragung via DataSnap im Appserver funktionierten, inkl. ein paar nutzerabhängiger Columns und 'nem "Bug" beim Übertragen von TEXT-Feldern.
> mehrere langdauernde SELECTs im Apps, bei Abfrage umkopieren in MemoryDataSet (umkopieren geht schnell und können auch gleich der Feldtyp von TEXT auf VARCHAR und sessionabhänig berechnete Felder angehängt werden) und anschließend die "langsamere" Übertragung via DataSnap. Es kann/darf ja eh nur ein Client gleichzeitig auf das gecachte Query zugreifen.
Das Selbe bei Streams für unser DMS, denn viele Komponenten (LoadFromStream) mögen es nicht, dass der DataSnap-Stream auf der Zielseite -1 als Stream.Size liefert, wenn mal über 30KB im Stream stecken.

Jetzt sind die Queries als vorberechneter View im Postgres und nicht mehr in dem alten speicherschwachen 32 Bit-DataSnap-Apps (XE).