Discussion :

[camboui]

J'ai récupéré hier les drivers les plus récents dispo chez MS, OLEDB et ODBC.
(avec comme surprise la renaissance d'OLEDB, alors qu'il était obsolescent).

Je développe en C/C++ et j'utilise de préférence ODBC car il est plus performant qu'OLEDB (et pas rien qu'un peu...).
Dans la ConnectionString j'utilise Provider=SQLNCLI11 pour les accès OLEDB et Driver={SQL Server Native Client 11.0} pour les accès ODBC.

J'ai donc fait quelques tests simples avec les nouveaux drivers Provider=MSOLEDBSQL pour les accès OLEDB et Driver={ODBC Driver 17 for SQL Server} pour les accès ODBC.
La perte de performance est de l'ordre de 10% à 20%. C'est franchement décevant...
Pour ce test j'ai écrit un programme compilé sous VS2015, la DB étant sous SQL Server 2014. Seule la ConnectionString est différente.
En bref, pourquoi utiliser ces nouveaux drivers s'ils sont moins performants ?

Par ailleurs, j'utilise aussi les fonctions bcp_xxxx qui sont déclarées dans #include "sqlncli.h".
Je ne retrouve pas ces fichiers pour les nouveaux drivers.
EDIT: je l'ai (re)trouvé, c'est #include "msodbcsql.h" qu'il faut (ré)utiliser, comme par le passé.

[SQLpro]

J'ai récupéré hier les drivers les plus récents dispo chez MS, OLEDB et ODBC.
(avec comme surprise la renaissance d'OLEDB, alors qu'il était obsolescent).

Je développe en C/C++ et j'utilise de préférence ODBC car il est plus performant qu'OLEDB (et pas rien qu'un peu...).
Dans la ConnectionString j'utilise Provider=SQLNCLI11 pour les accès OLEDB et Driver={SQL Server Native Client 11.0} pour les accès ODBC.

J'ai donc fait quelques tests simples avec les nouveaux drivers Provider=MSOLEDBSQL pour les accès OLEDB et Driver={ODBC Driver 17 for SQL Server} pour les accès ODBC.
La perte de performance est de l'ordre de 10% à 20%. C'est franchement décevant...
Pour ce test j'ai écrit un programme compilé sous VS2015, la DB étant sous SQL Server 2014.

Avez-vous migré la base ou est-ce bien la même base dans le même serveur qui est utilisée ?

Seule la ConnectionString est différente.
En bref, pourquoi utiliser ces nouveaux drivers s'ils sont moins performants ?

Par ailleurs, j'utilise aussi les fonctions bcp_xxxx qui sont déclarées dans #include "sqlncli.h".
Je ne retrouve pas ces fichiers pour les nouveaux drivers.
EDIT: je l'ai (re)trouvé, c'est #include "msodbcsql.h" qu'il faut (ré)utiliser, comme par le passé.

Il ne faut pas utiliser ces fonctions dans du code applicatif, à moins que vous ne soyez en train d'écrire vos propres drivers à la place de ODBC ou OLEDB... elle peuvent générer des problèmes d'accès, de contention et de blocage.

Si vous voulez faire du BCP, utilisez l'utilitaire en ligne de commande BCP.exe.

A +

[camboui]

Avez-vous migré la base ou est-ce bien la même base dans le même serveur qui est utilisée ?

Aucune migration, aucun changement, si ce n'est d'avoir installer les driver OLEDB 18.2.2.0 et ODBC 17.3.1.1 sur mon desktop (Windows 10 Pro).
Le serveur fait tourner une instance SQL Server 2014 sous Windows Server 2008R2 (HP bi-processeur xéon, 32GB).
Le test consiste simplement à récupérer près de 6500000 de lignes depuis 4 tables occupant plus d'un GB de mémoire (les chaînes CHAR et VARCHAR étant codées en CP1252, pas de WCHAR ni WVARCHAR).

J'ai ensuite installé les drivers sur ce serveur pour faire le test en accès DB local direct. La différence entre les anciens et les nouveaux drivers est encore plus marquée au détriment de ces derniers...

Il ne faut pas utiliser ces fonctions dans du code applicatif, à moins que vous ne soyez en train d'écrire vos propres drivers à la place de ODBC ou OLEDB... elle peuvent générer des problèmes d'accès, de contention et de blocage.

Si vous voulez faire du BCP, utilisez l'utilitaire en ligne de commande BCP.exe.

A +

Euh... pardon ?
C'est comme dire d'utiliser sqlcmd.exe et cesser d'utiliser les API en programmation...

Voici la doc MS pour utiliser ODBC et son extension spécifique pour SQL Server pour faire du bulk copy:
* SQL Server native client ODBC
Sous section bulk copy:
* Performing Bulk Copy Operations ODBC
Et, surtout, ce qui nous intéresse en C/C++:
* Bulk Copying From Program Variables
Je n'y ai pas vu qu'il ne faut pas l'utiliser
Et puis, ça fait 15 ans que je l'utilise avec succès...


Pour en revenir au problème de perfs entre les anciens drivers "SQL Server Native Client" et les nouveaux "ODBC Driver for SQL Server", je suis surpris par le recul, d'autant plus que que les "Native Client" sont désormais obsolètes semble-t-il:
* https://blogs.msdn.microsoft.com/sql...cle-explained/
* https://docs.microsoft.com/en-us/sql...ts-allversions
Bref, contrariant...

[SQLpro]

2 changements important ont été opérés au niveau des primitives BULK :
1) autrefois jusqu'à une certaine version c'était la DB-Library et non ODBC par lequel on "tuyautait" les données
2) BULK a été parallélisé à partir de la version 2008 de SQL Server (me semble t-il)

Je pense plutôt au 2, et donc de nouveaux réglages sont apparus pour piloter le multithreading......

A +