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.