Les pièges de WinDev + OLEDB + SQL Server

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.

Excellent

J'ai regardé rapidement mais il faudra que je regarde ça en détail, c'est très interessant. Merci de partager votre expérience OleDb Windev.

Bonjour,

J'ai mis à jour les 2 projets :
- Correction du test des agrégats et connexions TCP.
- Utilisation d'un curseur forward only pour la comparaison avec SQLExec/SQLAvance.
- Ajout d'un SELECT avec un plus gros résultat pour la comparaison SQLExec/HExécuteRequêteSQL (avantage grandement SQLExec).
- Ajout d'un petit commentaire pour dire que le curseur forward only est aussi rapide que le curseur client sur les requêtes de modif.

:merci: beaucoup pour ce programme très instructif ! :ccool:

Super !
Très intéressant.

Pour PostgreSQL, il y a plusieurs drivers OLE DB qui sont maintenus, je vais tester tout ça si je trouve le temps...

Au fait, OLE DB n'a plus que 7 ans à vivre :aie:
http://www.developpez.com/actu/36666...s-aux-donnees/

Bonjour,

Certains m'ont demandé de retrouver les projets de test.
Donc les voici.

Bonjour ,
Il y 'a qulqu'un qui a travaillé avec windev+SQL SERVER2008 +accès OLEDB

des requetes (jointure entre deux tables ) du genre (Select ( ( Personel.PRENOM + ' ') + Personel.NOM ) AS NOM )

C'est pas fonctionnelle chez moi .Et vous ?

Bonjour,

je vais déterrer ce post bien que Microsoft abandonne OLEDB pour SQL server à partir de la version 2014 donc cela n'a plus beaucoup d'importance

Mais je voulais souligner que ayant été confronté à ces problème il y a quelques années, j'ai téléchargé le petit programme de Hibernatus34 ( merci à lui ) pour le faire tourner dans sa version originale Windev 16 ( donc pas d'amélioration à ce niveau ) sur SQL server 2012 via OLEDB....

Et là surprise... plus aucun port TCP ne reste ouvert, plus de différence significative entre SqlExec, HExecuteRequeteSQL ou même les ordres Hxxxx.. la seule chose qui n'a pas changé est le POUR TOUT qui rafraîchi la requête au contraire de HlitPremier avec HSans rafraichir, ennuyeux mais pas bloquant..

Alors puisque le framework de WinDev est resté identique et que seule la version SQLserver et OLEDB à changé, j'ai plutôt tendance à imputer le problème à Microsoft, et c'était d'ailleurs à l'époque la réponse du S.T. de PCSOFT, mais ce qui n'était pas l'avis des DBA à l'époque qui bien entendu n'ont jamais voulu remettre la technologie de Microsoft en cause... bien entendu Microsoft est parfait et surtout leurs solutions sont pérennes car jamais ils ne discontinuent un produit, surtout quand ils est très utilisé…. 8-)

Merci à tous pour le partage de vos expérience.

Excellent travail.