SOAP / WebService ERemodeException beim Umstieg D6->D7

[Mavarik]

Hallo Zusammen!

Ich verzweifel hier noch...

Habe habe ein Programm von D6 auf D7 umgestellt und erhalte jetzt immer eine Exception bei einem
WebService/SOAP Zugriff...

Ich habe am Source nichts geändert... Muss also ein Fehler im "Marschaller" sein... Passiert auch "nur" bei TDatetime werten...

Hat jemand eine Idee?

Danke im Voraus Frank :coder:

[Bernhard Geyer]

Sind beide Seiten Delphi 6-Apps? Falls ja was passiert wenn beide Seiten aktualisiert werden?

AFAIK haben ältere Delphi-Versionen Interop-Probleme mit anderen Systemen welche in neueren Versionen korrigiert wurden.

[Mavarik]

Hi!

Serverseitig ist weiterhin D6.2 (Habe ich leider nicht "mehr" im Source)

Daher brauche ich eine FIX... Ist sicherlich ein Fehler im D7 hatte ich auch schon mit anderen Versionen...

Nach meinem Wissen ist der Fehler erst mit D2005 behoben... D2005 kann ich aber leider nicht nehmen..

Frank

[Bernhard Geyer]

Zitat:

Zitat von Mavarik

Hi!

Serverseitig ist weiterhin D6.2 (Habe ich leider nicht "mehr" im Source)

Daher brauche ich eine FIX... Ist sicherlich ein Fehler im D7 hatte ich auch schon mit anderen Versionen...

Nach meinem Wissen ist der Fehler erst mit D2005 behoben... D2005 kann ich aber leider nicht nehmen..

Frank

Schau dir mal den QC-Eintrag 7860 (Suche im Bereich SOAP mit Suchbegriff DateTime)

[Mavarik]

hmm Danke...

Leider verstehe ich das nicht...

Es gibt sicherlich ein Path für die SOAP Sourcen... Habe jedoch nix gefunden..

Frank

[Bernhard Geyer]

Zitat:

Zitat von Mavarik

Es gibt sicherlich ein Path für die SOAP Sourcen... Habe jedoch nix gefunden..

Der Patch heißt Delphi 2006 :-)

Im Bereich SOAP gab es auch mal Inoffizielle Patches welche über die Newsgroups verteilt wurden. Aber ob diese noch irgendwo zu finden sind bzw. ob das nicht auch "nur" für D6 gemacht wurde weiß ich leider nicht mehr.

[Mavarik]

Ich habs!

D6 Codiert ein TDatetime als Double in den XML File
D7 und ff. jedoch als TXSDatetime.

Also nicht 237827,123123 sondern 03-07-2006T20:30:02+001 oder so :-)

Ich habe einfach den Record für den SOAP in der *Intf Datei von TDateTime auf Double geändert und schon funktioniert wieder alles...

Grüsse Frank :coder:

TYPISCH Borland... Einfach mal wieder etwas ändern ohne ein IFDEF...
Und ich hätte fast 2500 CD verschickt mit diesem Fehler...

[Bernhard Geyer]

Zitat:

Zitat von Mavarik

Ich habs!

D6 Codiert ein TDatetime als Double in den XML File
D7 und ff. jedoch als TXSDatetime.

Also nicht 237827,123123 sondern 03-07-2006T20:30:02+001 oder so :-)

Also wurde nur ein Bug der D6-Implementierung gefixt. Denn für Datumswerte ist nunmal TXSDatetime vorgesehen.
Das gleiche Problem hätttest Du wenn du z.B. einen.NET oder PHP-SOAP-Server/Client bedienen willst.

Zitat:

Zitat von Mavarik

Ich habe einfach den Record für den SOAP in der *Intf Datei von TDateTime auf Double geändert und schon funktioniert wieder alles...

Du meinst du hast nur das verhalten auf das eigentlich falsche Verhalten von D6 zurückgestellt. Eine Lösung im Bezug auf Kompatiblität mit anderen Systemen ist das nicht.

Zitat:

Zitat von Mavarik

TYPISCH Borland... Einfach mal wieder etwas ändern ohne ein IFDEF...
Und ich hätte fast 2500 CD verschickt mit diesem Fehler...

Wie schon gesagt. Hier wurde nur die Implementierung so geändert das es Standardkonformer wurde. Dumm nur wenn du dieses verhalten benötigst weil du nicht beide Teile (Client+Server) aktualisierst. Wäre vermutlich auch mit mehr Aufwand verbunden.

[Mavarik]

OT:

Zitat:

Zitat von Bernhard Geyer

Also wurde nur ein Bug der D6-Implementierung gefixt. Denn für Datumswerte ist nunmal TXSDatetime vorgesehen.
Das gleiche Problem hätttest Du wenn du z.B. einen.NET oder PHP-SOAP-Server/Client bedienen willst.

Zugegeben da hast Du recht... Aber wie stellt sich B. das vor? Unzählige Programmierer haben Millionen Versionen "draußen" die halt so arbeiten...
Sollen jetzt alle Clients und Server Upgedatet werden, nur weil B. einen Fehler gefixed hat? Wer soll das bezahlen?

Zitat:

Zitat von Bernhard Geyer

Du meinst du hast nur das verhalten auf das eigentlich falsche Verhalten von D6 zurückgestellt. Eine Lösung im Bezug auf Kompatiblität mit anderen Systemen ist das nicht.

Ja auch richtig, aber wo ist das Problem ein Boolean aufzunehmen "OldDatetime_style"

Zitat:

Zitat von Bernhard Geyer

Wie schon gesagt. Hier wurde nur die Implementierung so geändert das es Standardkonformer wurde. Dumm nur wenn du dieses verhalten benötigst weil du nicht beide Teile (Client+Server) aktualisierst. Wäre vermutlich auch mit mehr Aufwand verbunden.

Es geht hier nicht um mehr Aufwand... Ich habe jetzt "nur" ca. 2500 Kunden... Und es gibt auch Anbieter die Ihre Kunden garnicht kennen... (Share/Freeware)

Frank

[Bernhard Geyer]

Zitat:

Zitat von Mavarik

Zugegeben da hast Du recht... Aber wie stellt sich B. das vor? Unzählige Programmierer haben Millionen Versionen "draußen" die halt so arbeiten...
Sollen jetzt alle Clients und Server Upgedatet werden, nur weil B. einen Fehler gefixed hat? Wer soll das bezahlen?

Wo ist das Problem? Definiere in der Intefacedefinition als Double. Oder lass die bisherige Version stehen und setze eine 2te Instanz auf die mit dem richtigen Typ arbeitet. Nach 1-2 Jahren wenn auch der letzte auf die neue Version aktualisiert hat schaltest du die alte Instanz ab.

Zitat:

Zitat von Mavarik

Ja auch richtig, aber wo ist das Problem ein Boolean aufzunehmen "OldDatetime_style"

Dann auch noch eine OldBoolean_style (da gabs am Anfang auch Probleme) und ein OldArray_style und ....

Zitat:

Zitat von Mavarik

Es geht hier nicht um mehr Aufwand... Ich habe jetzt "nur" ca. 2500 Kunden... Und es gibt auch Anbieter die Ihre Kunden garnicht kennen... (Share/Freeware)

Lösungsmöglichkeiten wurden genannt. Man soll nicht auf gedeih und verderb bis in alle Zeiten Bugs weiterpflegen.