Delphi 10 und Delphi 10.2.2 Fehler

[himitsu]

ERROR_INTERNET_FORCE_RETRY
Wow, der erste Treffer mit 14 Jahren immernoch so aktuell.
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).