Delphi 10.4 Sydney - Erste Eindrücke

[Uwe Raabe]

Zitat von twein:

Mit den vorherigen Versionen war es ein "TTimeField" jetzt ist es ein "TWideStringField"

Kannst du das auf ein simples Beispiel runterbrechen?

[twein]

Nachdem ich das Handtuch wieder aufgehoben habe,
hat sich dann doch wieder einiges erledigt.

[QUOTE=twein;1466406]

Zitat von jaenicke:

Zitat von twein:

Fehlschlag beim Start: FireDAC Property .AsDateTime für meine Klasse für eine Datenbankfeld Time (MS-SQL-Server) kann nicht mehr verwendet werden.

Ist das ein TDateTimeField oder ein TSQLTimeStampField? Hier scheint es zu gehen.
Lese- oder Schreibzugriff? Und was passiert?

Exception message : '12:00:00.0000000' ist keine gültige Datums- und Uhrzeitangabe
Depending on the error condition, it might be possible to restart the application.
Exception class : EConvertError

Mit den vorherigen Versionen war es ein "TTimeField" jetzt ist es ein "TWideStringField"
und ".AsSQLTimeStamp" funktioniert auch nicht!

Nachdem ich nun "Microsoft SQL Server Management Studio v18.5" installiert habe, ist der Feldtyp wieder richtig.
Dann war es wohl ein Treiber-Problem von Windows10 Pro.

Da hätte ich nicht gedacht, das Window10 -1909 so einen so alten MSSQL-Treiber mitbringt, bzw. bin mir eigentlich nicht sicher, von welcher Install-Routine der installiert wird.
Es bleiben ja nur
1. Windows
2. Office oder
3. Delphi

Jetzt funktioniert meine Anwendung auch wieder einwandfrei, ohne umzustricken.

[twein]

Zitat von himitsu:

Du kannst das TTimeField natürlich auch selbst erstellen, anstatt automatisch erstellen zu lassen,
oder bau einfach in dein SELECT einen CAST zu einem anderen Time-Typen, welchen deine DB-Komponente versteht.

Danke für den Hinweis!

Meine Anwendung läuft sauber auf mind. 4 unterschiedlichen SQL-Datenbanken. (MS-SQL, mySQL, PGSQL und SQLite)
Deswegen verzichte ich auf diese diversen Zuordnungen.

[Bernhard Geyer]

Zitat von twein:

Nachdem ich nun "Microsoft SQL Server Management Studio v18.5" installiert habe, ist der Feldtyp wieder richtig.
Dann war es wohl ein Treiber-Problem von Windows10 Pro.

Da hätte ich nicht gedacht, das Window10 -1909 so einen so alten MSSQL-Treiber mitbringt, bzw. bin mir eigentlich nicht sicher, von welcher Install-Routine der installiert wird.
Es bleiben ja nur
1. Windows
2. Office oder
3. Delphi

Eigentlich ist die ADO/OLEDB-Schnittstelle seit W2k integraler Bestandteil von Windows und sollte mit Windows-Update aktualisiert werden.
Aber nachdem ja seit einiger Zeit MS wieder auf "ODBC ist ja viel toller" läuft, könnte hier vermutlich auch mittlerweile andere MS-Tool hier querschießen.
Im Nachhinein den Schuldigen zu finden ist schwierig. Delphi kann nur im Rahmen der eigenen pas-Dateien schuld sein, was aber hier dann doch nicht der Fall ist.

[venice2]

Mein Fazit.

Zitat:

Da muss man sich wirklich fragen, warum man die doch sehr hohe "Delphi Enterprise Update Subscription" zahlt!

Delphi ist zur melkenden Kohle-Milch Sau avanciert.
Bei jeder neuen Version wird dermaßen im Kernel rum-gepfuscht das erstmal gar nichts mehr geht.
Man ist auf die Gnade des Support diverser Drittanbieter angewiesen um seine Projekt fortführen zu können.

Warum tut ihr euch das überhaupt noch an migriert euren Code nach VS-Studio und arbeitet mit einer für euch genehmen Programmiersprache.
Falls nicht, es ist wie beim ewigen Windows 10 Beta- System. Wartet gefühlt mindestens ein Halbes Jahr und verwendet erst dann die neue Version.

Was glaubt ihr eigentlich was passieren würde wenn M$ so einen Müll mit VS-Studio produzieren würde.
Ja. Die Community würde auf die Palme gehen.

Aber nein ihr seit ja eingefleischte Delphi Fans die kennen es nicht anders und sind es letztendlich selber schuld wenn sie das Theater ständig mitmachen.

Zitat:

Im Nachhinein den Schuldigen zu finden ist schwierig.

Da ist nichts schwierig und redet nicht alles fein.
Der Vertrieb\Entwickler der Delphi anbietet ist es schuld, bleib doch einfach mal sachlich.

[twein]

Zitat von Bernhard Geyer:

Zitat:

Rein meine persönliche Meinung (Sorry:Und das muss jetzt auch mal raus):
Seit "Delphi 10 Seattle" warte ich auf einen Durchbruch und wirkliche Verbesserungen.

Das sind m.E. schon einge Dinge dabei die das leben einfacher machen. Manche lernt man erst zu schätzen wenn man (wegen Altcodepflege) mal wieder ein altes Delphi nutzen müsste.
Bei mir ist 10.2 (10.4 erst "nur alles zum compilieren gebracht) erheblich produktiver als die vorherigen Versionen (XE6 und Delphi 6).

Ich warte nicht seit Delphi6, sondern seit "Delphi 10 Seattle"!

[Bernhard Geyer]

Zitat von venice2:

Bei jeder neuen Version wird dermaßen im Kernel rum-gepfuscht das ermal gar nichts mehr geht.

Komisch nur das ich (mit Anpassung an 3th-Party-Libs unsere App in wenigen Stunden auf 10.4 angepast habe?

Zitat von venice2:

Warum tut ihr euch das überhaupt noch an migriert euren Code nach VS-Studio und arbeitet mit einer für euch genehmen Programmiersprache.

Und setzt auf "Die Zukunftstrategie die nach 2-3 Jahren abgekündigt wird?
Die IDE mag zwar ganz gut sein, aber die Haltbarkeit der "Zukunftstechniken" bei MS ist doch mittlerweile sehr kurz ...

Zitat von venice2:

Was glaubt ihr eigentlich was passieren würde wenn M$ so einen Müll mit VS-Studio produzieren würde.
Ja. Die Community würde auf die Palme gehen.

MS hat auch öfter schon VS.Studie-Versionen auf den Markt gebracht die alles andere als gut angekommen sind.

Zitat:

Im Nachhinein den Schuldigen zu finden ist schwierig.

twein hat ein MS-Anwendung installiert und dann ging es.
War wohl in dieser Konstellation Delphi schuld oder doch die MS-Installtionen, welche scheinbar etwas an OLEDB verstellt hatte.

[venice2]

Zu all deinen Statements gibt es nur eins zu sagen.
Rede dir das alles selbst gern ein.

Es gibt halt sogenannte suggerierte Helden bei denen geht immer alles. (Ist ja Delphi, klar doch)

[twein]

Zitat von Bernhard Geyer:

Eigentlich ist die ADO/OLEDB-Schnittstelle seit W2k integraler Bestandteil von Windows und sollte mit Windows-Update aktualisiert werden.
Aber nachdem ja seit einiger Zeit MS wieder auf "ODBC ist ja viel toller" läuft, könnte hier vermutlich auch mittlerweile andere MS-Tool hier querschießen.
Im Nachhinein den Schuldigen zu finden ist schwierig. Delphi kann nur im Rahmen der eigenen pas-Dateien schuld sein, was aber hier dann doch nicht der Fall ist.

Es ist tatsächlich der Wahnsinn!
Microsoft liefert mit "Windows10 1909" einen ODBC Treiber der Version 10.0.18362.1 mit.

Nun habe ich 18.3.0000.0

Der Unterschied hört sich nach Lichtjahren an.

[jaenicke]

Zitat von twein:

Mit den vorherigen Versionen war es ein "TTimeField" jetzt ist es ein "TWideStringField"
und ".AsSQLTimeStamp" funktioniert auch nicht!

Das liegt am Treiber, wie du schon festgestellt hast. Ohne den Native Client bzw. dessen Nachfolger macht die Verwendung von MS-SQL echt keinen Spaß. Der mitgelieferte Treiber ist nicht schön...

Bei mir klappt es aber auch mit dem einfachen "SQL Server" Treiber (SQLSRV32.DLL) in Version 10.00.18362. Ich bekomme allerdings in den FireDAC Informationen die Meldung "Warnung: ODBC-Treiber für "SQL Server" ist veraltet. Führen Sie ein Upgrade auf einen neueren ODBC-Treiber für SQL Server durch.".

Es gibt die Funktion TDataSet.GetFieldClass in Data.DB, wo man sich ggf. anschauen könnte welcher Feldtyp das ist und dann mit der alten Version vergleichen, ebenso in TFieldDef.GetFieldClass.

Zitat von twein:

Ja der Defender läuft und es ist alles identisch, wie auch mit der Version 10.3.3.
Es war mit meinem aktuellen Projekt!
Mit einem leeren Projekt, lässt sich die Funktion ja nicht wirklich beurteilen.

Das Problem ist aber, dass hier nun ein separater Prozess verwendet wird. Dadurch ist die aktuelle Funktionalität nicht vergleichbar und es kann durchaus am Defender liegen. Der ist ja ohnehin im Vergleich zu anderen Antivirentools deutlich langsamer, auch wenn das in Tests seltsamerweise nie auffällt. Es ist aber sogar ohne Messung sichtbar, wenn man es vergleicht...

Du kannst die alte Code Insight Funktionalität aber wieder verwenden, das ist einstellbar.

Zitat von Bernhard Geyer:

Mit 10.3 haben sich Wertmapping in DataTypeValues (Data.Win.ADODB.pas).
Könnte als schon zu 10.3 ein Problem vorhanden sein.

Das ist ADO, das hat mit FireDAC nichts zu tun, oder?

Zitat von venice2:

Bei jeder neuen Version wird dermaßen im Kernel rum-gepfuscht das erstmal gar nichts mehr geht.

In Foren findet man natürlich vor allem auftretende Probleme, aber es gibt auch viele, bei denen es einfach läuft.
Das Problem mit dem Stringgrid hatte ich wegen eines Forenposts gefunden. Unsere eigenen Projekte machen keine Probleme und die Umstellung war mit wenigen Handgriffen in den Buildskripts erledigt...