Delphi 10.4 Sydney - Erste Eindrücke

[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.

[Bernhard Geyer]

Das mit "FreeAndNil" wird gerade auch hier besprochen:

https://www.delphipraxis.net/204531-...ml#post1466330

[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.

[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?

[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...

[Bernhard Geyer]

Zitat von jaenicke:

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...

Auch werden diese nicht mehr mit Windows Update verteilt.
Etwas was so schön funktioniert hatte (mit W2k und neuer") wird jetzt wieder kaputt gemacht.

Bisher keine Problem. Kann auch daran liegen das wir direkt auf ADO/OLEDB gehen ohne den Delphi-Wrapper ADOGo.

Zitat von jaenicke:

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

Yo, überlesen.

[Redeemer]

Zitat von 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.

Kleiner Nachtrag noch:
Es muss (egal auf welcher Windows-Version) der SQL Server Native Client 14 installiert sein, um Features zu nutzen, die nach 2005 hinzugekommen sind, z.B. date, time oder Standard-Instanzen (TCP). Die Version 14 ist AFAIK die einzige Version vom SQL Server Native Client, es gibt aber verschiedeme Builds, die sehr seltsame Bugs haben, teils auch böse Regressionen. Die neueste Version hat keine mit bekannten Bugs, das Produkt ist seit langem eingestellt.
Das hat nichts mit Delphi oder der Zugriffskomponente zu tun. Auch relativ unabhängige Komponenten wie Devart haben ohne aktuelle SQL-Server-Client-Version besagte Macken.
Da der SQL Server Native Client auf allen Clients installiert werden müsste, kann es zur Reduktion von Abhängigkeiten sinnvoll sein, dir eine alternative AsDateTime-Methode zu schreiben (als class helper), die das Feld als Varchar auffasst und das Ergebnis von AsString selbst interpretiert, wenn der FieldType falsch ist. Ich weiß jetzt nicht, wie sich FieldClass davon unterscheidet, aber der FieldType ist definitiv falsch, wenn der SQL Server Native Client 14 nicht installiert ist.