MSSQL - wie noch in Zukunft drauf zugreifen.

[mkinzler]

Nein ist nur ein Eindruck.

[API]

Zitat:

Zitat von mkinzler (Beitrag 1411351)

Der neue Status scheint wohl redeprecate zu sein.

Quelle: https://blogs.msdn.microsoft.com/sql...or-sql-server/

[mkinzler]

Den ersten Satz und den Link übersieht man.

[ventiseis]

Die meisten Beispiele beziehen sich ja immer auf ConnectionStrings und nicht direkt auf Delphi/dbExpress.

Wie siehts es eigentlich auf der Delphi-Seite aus? Kann irgendwas kaputt gehen, wenn ich statt

Code:

VendorLib=sqlncli10.dll

nun

Code:

VendorLib=sqloledb.dll

in die dbxdrivers.ini eintrage? Funktioniert das überhaupt mit dem mitgelieferten dbExpress-Treiber? Ist das jetzt zu empfehlen, da der NativeClient deprecated ist?

Die Dokumentation sagt auch nix sinnvolles darüber aus - nach SQL Server 2008 kommt nix mehr :? (hier funktioniert der SQL Server 2017 mit sqlncli10.dll ohne Probleme)

[p80286]

Der letzte Stand der Irrfahrt ist wohl https://blogs.msdn.microsoft.com/sql...or-sql-server/

Demnach, wenn ich es richtig interpretiere, ist msoledbsql der letzte Stand, aber für den SQL-Server nicht unbedingt notwendig. Aber wir kennen das ja, Zuverlässigkeit ist nicht unbedingt die Stärke von MS. Im Zweifel würde ich alle drei bereithalten (und es gibt ja noch 32 und 64 Bit) und testen so gut es geht.

(ich hab mir den SQL-express vor kurzem installiert um ein paar Access-Dateien zu lesen, und es war das Chaos in Tüten, z.zt. funktioniert Provider=SQLOLEDB.1 noch zufriedenstellend)

Gruß
K-H

[generic]

Zitat:

Zitat von p80286 (Beitrag 1411380)

Der letzte Stand der Irrfahrt ist wohl https://blogs.msdn.microsoft.com/sql...or-sql-server/

(ich hab mir den SQL-express vor kurzem installiert um ein paar Access-Dateien zu lesen, und es war das Chaos in Tüten, z.zt. funktioniert Provider=SQLOLEDB.1 noch zufriedenstellend)

Ja, dass ist der Treiber für SQLServer 8/2000 und dieser ist seit Windows 2000 imho Bestandteil vom OS. Der Treiber hat aber evtl. Probleme mit den neuen Datentypen. Zumindest unter Access 97 hatten wir da mal Problem mit "Date" und den 64bit Typen.

Aktuell dürfte es der OLE DB Treiber mit Namen "SQLNCLI11" sein.

[HolgerX]

Hmm..

Ich hab noch nie den SQLOLEDB.1 für Access verwendet ;)

Endweder
Microsoft.Jet.OLEDB.4.0 (bis Access 2003)
oder
Microsoft.ACE.OLEDB.12.0 (ab Access 2007)

https://www.connectionstrings.com/access/

Für Verbindungen mit MS-SQL-Server ist in Windows (so ab W2000) immer der SQLOLEDB.1 per se installiert.
Für die Verwendung des 'SQL Server Native Client OLE DB Provider' SQLNCLIxx muss dieser auf dem PC installiert werden, da dieser nicht per se vorhanden ist.

Hier gibt es verschiedenen Versionen:

'SQLNCLI'; // SQL Native Client 9.0 OLE DB Provider SQL Server 2005
'SQLNCLI10'; // SQL Native Client 10.0 OLE DB Provider SQL Server 2008
'SQLNCLI11'; // SQL Native Client 11.0 OLE DB Provider SQL Server 2012 , 2014 , 2016

Mit den verschiedenen Versionen sind weitere Funktionen für die Verbindung und auch Spezialitäten der entsprechenden SQL-Server Versionen gekommen.

Für die 'einfache' Verbindung über ADO genügt aber immer noch der 'SQLOLEDB.1', selbst für SQL-Server 2016/18.

Mit dem SQL-Server 2018 sollte der Native Client sterben, was jedoch seitens MS rückgängig gemacht wurde und der 'MSOLEDBSQL' als neuer OLE-DB Treiber gekommen ist.

https://docs.microsoft.com/de-de/sql...ql-server-2017

Auch dieser Treiber muss explizit installiert werden.

[ventiseis]

Gibt es denn Erfahrungswerte für den neuesten Treiber (MSOLEDBSQL) in Verbindung mit dbExress? Aktuell verwenden wir hier noch den älteren NativeClient, der zwar funktioniert, aber als veraltet gilt.

Ich versuchte dies schon mal herauszufinden, allerdings hat mir niemand geantwortet :-(