Discussion :

[sHnouL]

Bonjour,

L'accès natif est (un peu) plus rapide sur presque toutes les fonctions.
Mais il pose quelques problèmes pour le moment, comme un changement de session entre les transactions (à cause du mode MARS), ou la confusion entre NULL et 0 dans les paramètres de requêtes, une mauvaise gestion des messages d'erreur...
Personnellement, en ayant développé tous les outils pour m'en passer, je lui préfère l'accès OLE DB "normal", qui est mieux supporté (et pourtant gratuit).
L'accès natif existe en version ODBC, mais il ne fonctionne pas encore aussi bien que la version OLE DB.

L'accès ODBC par OLEDB posait des problèmes de blocages de tables, je pense qu'il faut l'éviter.

Sachez que l'accès OLE DB ou ODBC, que ça soit avec l'accès "natif" ou "normal", nécessite l'installation d'un driver côté client, au moins si on veut une gestion des dates correcte.

Merci pour votre réponse Hibernatus.
Alors par l’accès OLE DB l'utilisation des fonction "Hajoute()" , "Hmodifie()","HLitRecherchePremier()", etc... n'est pas possible ? Il faut passer par la fonction HExecuteRequete() ?

J'ai essayer d’utilisé la fonction HLitRecherchePremier() pour faire un SELECT tres simple. Et la requête est très longue. J'ai l'impression que Windev charge toute la table en mémoire. Alors que avec la fonction HExecuteRequete() le résultat est instantané !

Merci

[WDKyle]

Bonjour,

Que ce soit en accès natif ou non, HLitRecherchePremier c'est le mal

[Hibernatus34]

Normalement HLitRecherchePremier devrait fonctionner correctement.
Et en accès natif ça fait partie des fonctions réellement plus rapides.

Il y a peu de contre-indications à HAjoute, HModifie etc. à part un problème de curseur pour HModifie et HSupprime en accès OLEDB "normal", et des problèmes de conversion de données (WinDev va mal gérer la précision des dates et décimaux par exemple).

Personnellement j'utilise encore pas mal HAjoute, mais pas du tout HModifie/HSupprime/HLitRecherchePremier. Mais c'est parce que j'ai l'équivalent en mieux dans mes libs, sinon ces fonctions restent utiles pour alléger le code et le rendre plus facilement maintenable, au lieu de le cribler de requêtes.

Vous aurez du mal à atteindre les performances de HAjoute avec des requêtes, par exemple.

[sHnouL]

Non le HLitRecherchePremier() n'est pas du-tout rapide. Peux être c'est parce que je travail actuellement sur Firebird 2.1.
J'essayerais quand j'aurais SQL Server 2012 debut séptembre.
En tout cas merci Hybernatus pour cette éclaircissement sur les différentes possibilité pour se connecté au une base SQL Server.
Je ne manquerais pas de revenir sur ce topic pour donné mon ressenti sur les différentes méthode d’accès est sur la rapidité des fonctions "H".

A+

[mononeurone]

Bonjour,

Mais il pose quelques problèmes pour le moment, comme un changement de session entre les transactions (à cause du mode MARS), ou la confusion entre NULL et 0 dans les paramètres de requêtes, une mauvaise gestion des messages d'erreur...

Bonjour,

Remarque intéressante dans mon cas, je suis tombé sur ce topic en m'arrachant les cheveux avec une connexion ODBC :

Je configure une connexion ODBC avec sqlconnecte sur un sqlserver 2012 ou 2014
J'execute une requete par SQlexec, ca marche bien
J'en ouvre une seconde par SQLexec et la seconde plante en indiquant "[Microsoft][SQL Server Native Client 11.0]Connection is busy with results for another command"
Une recherche m'a orienté vers l'option MARS qui ne serait pas active par défaut bloquant l'ouverture de plusieurs requêtes dans une même connexion, mais je ne comprends pas comment je peux l'inclure dans mon sqlconnecte initial. Une idée peut être car je suis à court d'idées sur ce point? L'option "fait qu'une requête jointe au lieu de 2 imbriquées" ne m'est pas satisfaisante du fait de contraintes de temps et de développement indépendantes de ma volonté.

Du coup, pour en revenir au sujet initial, j'ai configuré la connexion en OLEDB mais j'avais des temps de réponses assez long, étonnant car ce devrait être plus rapide, cela venait probablement de la connexion par IP qui impliquait une résolution de nom ou d'IP que le pointage en local a permis de résoudre (fichier hosts windows, etc...). Après, vis-à-vis du client natif PC SOFT, ça me parait largement dispensable sur une logique coût-rapidité mais pratique dans une logique facilité d'emploi.