|
| Inicio → WINDEV 2024 → [Sql server 2005 express] accès natif moins rapide qu'OLEDB ?? |
| [Sql server 2005 express] accès natif moins rapide qu'OLEDB ?? |
| Iniciado por info, 19,dic. 2005 13:36 - 10 respuestas |
| |
| | | |
|
| |
Publicado el 19,diciembre 2005 - 13:36 |
Hello,
Voilà, j'ai créé deux tables commande et clients contenant respectivement 100'000 et 32'000 enregistrements.
Sous windev, j'affiche les Commandes dans un champ table "Commande", je me promène parmi les 100'000 enregistrements, et là surprise, c'est bien plus fluide par une connexion OLEDB (Sql native client), qu'avec le driver accès natif de windev (que j'ai téléchargé en version démo).
Si l'accès natif sql server de windev est supposé être spécialement optimisé pour windev, franchement j'y comprend rien...
Bien sur, j'emploie sql server 2005 express qui est quelque chose de nouveau, mais meme avec sql server 2000 entreprise ca fait pareil.
Excellent temps de réponse en OLEDb, super fluidité dans les table à fetch partiel, et en natif, ca rame comme si on était 12 à bosser en même temps.
Si qqn a de l'expérience de programmation windev avec sql server, j aimerai beaucoup connaitre son avis. |
| |
| |
| | | |
|
| | |
| |
Publicado el 19,diciembre 2005 - 15:21 |
Il faudrait regarder les requêtes exécutées dans le profile SQLSERVER pour savoir ce qu'il se passe exactement. La version de démo est souvent ralentie par le fait qu'elle mélange volontairement des caractères, et du coup des requêtes peut être erronées par la suite.
A+ |
| |
| |
| | | |
|
| | |
| |
Publicado el 19,diciembre 2005 - 16:11 |
salut,
je ne sais pas si c'est le cas pour l'accès natif sqlserver, mais pour celui d'oracle nous avons constaté que pcsoft envoi toujours un 'SELECT COUNT(*)' avant la requête elle-même, ce qui, dans certains cas prend du temps.
Par exemple
notre requete est 'SELECT * FROM FICHIER WHERE NUMERO0'
l'accès natif envoie 'SELECT * FROM FICHIER WHERE NUMERO0' puis notre requête
Par conséquent, sur certains de nos traitements, l'accès ODBC est plus rapide que l'accès natif. |
| |
| |
| | | |
|
| | |
| |
Publicado el 19,diciembre 2005 - 16:48 |
Merci,
Oui j'ai aperçu cette requete, c'est pour le dimensionnement de l'ascenseur, ce n'est pas si grave à mes yeux car dans mon cas, ce sont des millisecondes qui se perdent pour le count(*)...
Par contre, dans une table sans filtre, dans laquelle on suppose que le count(*) doit être très rapide, je me promène en haut en bas en cliquant l'ascenseur de ma table et j'ai les résultats suivants :
-EN oleDb, je glisse l ascenseur, je lache, hop 1 dixieme de seconde après c'est affiché!
-En accès natif, je glisse l'ascenseur, déjà là ça rame, ça bouge par à coup!!!, je lache, ca fait 3 secondes avant de s'afficher!
C'est un véritable problème quoi... |
| |
| |
| | | |
|
| | |
| |
Publicado el 19,diciembre 2005 - 23:47 |
Moi j'ai un accès natif (pas de démo) et je n'ai pas ce type de pb.
D'autres témoignages ?
Ta table est directement sur le fichier, sur une requête ? quel est le code
de cette requête ? l'as tu optimisée avec l'optimiseur de requêtes ?
As tu testé aussi l'analyseur de performance de windev pour voir ou passe le
temps ?
Antoine
"Stef" <info@rmiconcept.ch> a écrit dans le message de news:
43a6c1a6$1@news.pcsoft.fr...
Merci,
Oui j'ai aperçu cette requete, c'est pour le dimensionnement de
l'ascenseur, ce n'est pas si grave à mes yeux car dans mon cas, ce sont
des millisecondes qui se perdent pour le count(*)...
Par contre, dans une table sans filtre, dans laquelle on suppose que le
count(*) doit être très rapide, je me promène en haut en bas en cliquant
l'ascenseur de ma table et j'ai les résultats suivants :
-EN oleDb, je glisse l ascenseur, je lache, hop 1 dixieme de seconde après
c'est affiché!
-En accès natif, je glisse l'ascenseur, déjà là ça rame, ça bouge par à
coup!!!, je lache, ca fait 3 secondes avant de s'afficher!
C'est un véritable problème quoi...
|
| |
| |
| | | |
|
| | |
| |
Publicado el 20,diciembre 2005 - 08:08 |
YORK a écrit :
salut,
je ne sais pas si c'est le cas pour l'accès natif sqlserver, mais pour celui d'oracle nous avons constaté que pcsoft envoi toujours un 'SELECT COUNT(*)' avant la requête elle-même, ce qui, dans certains cas prend du temps.
Par exemple
notre requete est 'SELECT * FROM FICHIER WHERE NUMERO0'
l'accès natif envoie 'SELECT * FROM FICHIER WHERE NUMERO0' puis notre requête
Par conséquent, sur certains de nos traitements, l'accès ODBC est plus rapide que l'accès natif.
Bonjour,
il semblerait que pour l'accès natif mysql ce soit le même genre de
chose sauf que ce ne sont pas des requêtes select count(*) mais 2 fois
la requête envoyée ...
--
Cordialement
chris |
| |
| |
| | | |
|
| | |
| |
Publicado el 20,diciembre 2005 - 10:13 |
Bonjour,
Pour l'exécution de 2x de la requête, je suppose que vous utillisez la fonction hlitpremier()
Regardez l'aide attentivement et ajouter le paramètre hSansRafraîchir et votre requête ne devrait être qu'exécutée une seule fois.
Claude. |
| |
| |
| | | |
|
| | |
| |
Publicado el 20,diciembre 2005 - 10:17 |
Ma table est directement liée au fichier, enfin à la table sql server,
c'est vraiment un champ table lié avec une liaison multi fichier sur
une colonne.
J'ose pas faire avec une requete parce qu'il faut la décrire dans
l'éditeur de requête, êt puis si j'ai plus d'une jointure, y'a un
problème de syntaxe.
Et puis en général, les tables basées sur des requêtes ne supportent
pas le fetch partiel, ca fait que je devrai charger 100'000
enregistrements dans la mémoire. Impensable...
Ce n'est pas un problème d'optimisation de la table, j'ai toutes les
clés qu'il faut et pour cause, ca n'explique pas pourquoi en OLEDB
c'est super fluide et en accès natif ça pose problème. Si ça marchait mal dans
les deux cas je remettrai en cause la structure, mais là c'est vraiment
pas le cas.
PS: Je disais aux développeurs qui se servent de sql server que je serai ravi de
connaitre leurs témoignages avant de faire le choix d'acquérir ou non l'accès natif. |
| |
| |
| | | |
|
| | |
| |
Publicado el 21,diciembre 2005 - 10:14 |
Y'a-t-il quelqu'un qui développe avec sql server?
Par quelle solution?
Accès natif ou OLE DB?
J'aimerai simplement savoir pourquoi cet accès natif me pose tant de problèmes. Juste que quelqu'un me dise qu'il utilise l'accès natif, que c'est bien et qu'il en est satisfait. |
| |
| |
| | | |
|
| | |
| |
Publicado el 22,diciembre 2005 - 09:33 |
Claude H a écrit :
Bonjour,
Pour l'exécution de 2x de la requête, je suppose que vous utillisez la fonction hlitpremier()
Regardez l'aide attentivement et ajouter le paramètre hSansRafraîchir et votre requête ne devrait être qu'exécutée une seule fois.
Claude.
Bonjour,
merci pour l'info. Je n'ai pas le temps de remettre en branle la
batterie de tests mais je vous tiens au courant. Par contre, mais là
aussi à vérifier, il me semble que le péhonomène se protuit sur les
instructions "pour tout" et là pas de hlitpremier "explicite".
--
Cordialement
chris |
| |
| |
| | | |
|
| | |
| |
Publicado el 17,marzo 2006 - 17:12 |
Bonjours
Je travaille avec l'accès natif SQL server, et j'ai le même type de problème, un hlitrecherchepremier ou un hmodifie prend plus d'une seconde alors que de générer ma requête et de l'envoyer via un hexecuterequetesql prend moins de 50ms. C'est une différence énorme. J'ai déjà essayé sur 3 serveurs SQL Server différents dont une fois en faisant tourner mon application directement sur le serveur. Peu importe la puissance du server, les temps de réponses sont toujours aussi décevant. Ce n'est donc pas un problème serveur. Mon application tourne aussi sur une DB 400 via l'accès natif easycom, où je n'ai pas ce genre de problème. Quelqu'un aurait-il une solution autre que de dupliquer mon code en fonction de la DB que j'attaque? |
| |
| |
| | | |
|
| | | | |
| | |
|