Bonjour,
Après avoir travaillé sur un très gros projet HF à convertir en SQL Server via OLE DB, j'ai constaté quelques problèmes auxquels il faut faire attention.
Voici un petit projet quick & dirty qui illustre les points les plus croustillants.
Pour le tester, il faut un serveur SQL accessible via OLE DB par TCP/IP.
Dans "Provider" vous pouvez saisir "SQLOLEDB" pour SQL Server, ou "SQLNCLI" pour SQL Server 2005 ou "SQLNCLI10" pour 2008.
Si vous saisissez le provider "MSDASQL" et que dans "Serveur" vous mettez le nom d'une source ODBC, vous aurez "ODBC via OLE DB". Mais ça m'a l'air assez mauvais comme provider, il m'a semblé qu'un SELECT bloquait la table complète jusqu'à la fermeture de la requête, il faudra vérifier ça.
Enfin, il y a la possibilité de saisir le nom d'une source ODBC pour faire une petite comparaison de performances.
Les sujets abordés sont :
- Utiliser un curseur serveur (curseur par défaut) pour autre chose que des SELECT peut amoindrir les performances et la fiabilité
- Les SELECT agrégats gaspillent des ports TCP et peuvent bloquer toute connexion pendant quelques minutes
- Différence de performance entre SQLExec et HExécuteRequêteSQL
- Différence de performance entre OLE DB et ODBC
- Pourquoi il ne faut pas utiliser HModifie, sous peine de plantages rares et incompréhensibles
- hRequêteSansCorrection
- hLimiteParcours
- hSansRafraîchir, et le problème de POUR TOUT pour parcourir un résultat de requête
- Les sources de données locales qui ne le sont pas réellement
WD15 : http://www.mediafire.com/download.php?6tio7cr20ed9r7u
WD16 : http://www.mediafire.com/download.php?gy90lj2b05c2kg9
Note : j'ai pris soin de n'utiliser que du code SQL compatible avec n'importe quelle base (je crois), donc vous pouvez tester avec autre chose que SQL Server, mais je ne sais pas qui d'autre maintient un provider OLE DB.
Partager