|
FORUMS PROFESSIONNELS
WINDEV, WEBDEV et WINDEV Mobile |
| | | | | |
| SQL Server OLE DB tres lent en WD, tres rapide en Access ??? |
| Débuté par damien.lep, 13 fév. 2006 11:13 - 12 réponses |
| |
| | | |
|
| |
Posté le 13 février 2006 - 11:13 |
Hello tout le monde ...
Je programme actuellement en WinDev 9 et 10 sur une base
SQL Server 2000 via un acces OLE DB. Avant de migrer sous WD
nous utilisions le bon vieux access 2002.
Ce qui me surprend c est les temps d acces sur certaines requetes :
Par exemple une fonction simple qui me renvoye une table prend
4 secondes sous l analyseur de requete SQL Server (pour 76 lignes).
Sous WD9 elle prend 39 secondes (via un hexecuterequeteSQL en mode sans
correction) !!! ELLE PREND 43 SECONDES sous WD10 !!!!!!!
Le pire : sous Access elle met 6 secondes !
Il y a vraiment ici une grosse lacune sur les acces OLE DB ...
Dans ce cas WinDev ne fait pas mieux qu access, c est moyen !
Donc au final nous envisageons de prendre l acces natif SQL Server.
J ai lu beaucoup de chose a son sujet, des bonnes et des moins bonnes.
Etant donné que mon seul but est la rapidite d execution, cela vaut il le coup ?
Ce qui me fait peur, c est que les programmeurs WD semblent bouder les
bases SQL server et SQL CE d ailleur (pour Oracle ils sont bien oblige de s y mettre),
alors que ce sont de tres bonnes bases (bien superieures a mon gout aux HF !!
un exemple simple : les Foreign Keys ! je n imagine pas une base sans cela !)
Qu en est il vraiment ?
Merci de vos reponses.
Damien. |
| |
| |
| | | |
|
| | |
| |
Posté le 13 février 2006 - 11:56 |
Je me suis connecté via le driver SQL native client de sql server 2005 express (considéré comme de l'OLE DB), ça avait l'air de bien marcher pour ce que j'ai fait c'est à dire une table fichier de 100000 enregistrements. C'etait fluide et tout, par contre avec l'accès natif j'ai eu des ennuis (voir mon autre thread sur le sujet).
Malheureusement je n'ai pas la possibilité de tester avec sql server 2000.
Tiens nous au courant |
| |
| |
| | | |
|
| | |
| |
Posté le 13 février 2006 - 11:58 |
J ai peut etre un element de reponse !
Sous acces on ne lancait jamais de fonctions !
On utilisait plutot des procedures !!!!
Je viens d essayer sous WD d utiliser une proc
(qui appelle juste ma fonction)
-> le temps d execution passe de 50 secondes a 17 secondes !
????!!!! |
| |
| |
| | | |
|
| | |
| |
Posté le 13 février 2006 - 12:01 |
Bonjour,
Lors du passage de mes applications de HF à MaxDb, j'ai remarqué que l'accès via OLEDB était extremement lent, alors que l'accès ODBC "pur" fonctionne parfaitement.
Est-ce que tu as essayé d'accéder à ta base via ODBC ?
Frédéric. |
| |
| |
| | | |
|
| | |
| |
Posté le 13 février 2006 - 12:03 |
j'ai fait un test de rapidité pour OLEDB et l 'accés natif (accés sur reseau local), j'exécute une requété de selection simple, voici les résultats:
- Table qui contient 30000 enregistrement:
Accés natif:261 ms.
OLEDB : 1318 ms.
==> Accés natif plus rapide 5 fois.
- Table qui contient 200000 enregistrement:
Accés natif:542 ms.
OLEDB : 19384 ms.
==> Accés natif plus rapide 35 fois.
Rq: plus la taille est importante, plus OLEDB devient trés lent.
la solution Accés natif est trés raisonnable. |
| |
| |
| | | |
|
| | |
| |
Posté le 13 février 2006 - 12:03 |
j'ai oublié de dire que les test se sont fais sur une base SQL SERVER 2000 |
| |
| |
| | | |
|
| | |
| |
Posté le 13 février 2006 - 12:32 |
Merci pour toutes vos reponses ...
Je vais essayer au passage l acces ODCB voir ...
Sinon au niveau stabilite, fiabilite, que donne l acces natif SQL ?
Apparement ce n est pas compatible avec la derniere version de
SQL server ... (on n y est pas encore mais c est prevu)
De plus sur les rensignements du site, c est marque qu il faut payer
une licence par serveur... Donc en gros il en faut une pour le developpement,
et une par client qui l utilise ... C est bien cela ?
Voila merci encore,
Damien. |
| |
| |
| | | |
|
| | |
| |
Posté le 13 février 2006 - 12:46 |
J'utilise l'accès natif SQL Server ('normal' pas celui pour pocket) sur des applis 9, sans souci majeur. En plus il n'est pas cher il en faut seulement 1 par serveur, le nombre d'utilisateurs est illimité |
| |
| |
| | | |
|
| | |
| |
Posté le 13 février 2006 - 12:57 |
Et moi, je précise que mes essais concernent uniquement SQL server 2005 versions Express.
Pour Frederic Demilly:
Vous semblez avoir une certaine expérience de la programmation avec ODBC, sauriez-vous comment créer une table sur un fichier de 100'000 enregistrements sans tout charger en mémoire? (j'ai posté récemment un thread sur le sujet)
Je suis toujours à la recherche d'une base alternative à C/S, j ai pensé à postgres et à firebird mais par OLE DB c'est quasi impossible d'arriver à quelque chose de satisfaisant. Si je trouve comment offrir des interfaces utilisateurs de qualité avec ODBC, je change volontiers quitte à perdre le confort de l'analyse et des ordres HLit (que j'utilise presque pas de toute façon). |
| |
| |
| | | |
|
| | |
| |
Posté le 13 février 2006 - 12:58 |
Bonjour,
"Phil" <philippe.noireau@prive.com> a écrit dans le message de news:
43f06320$1@news.pcsoft.fr...
J'utilise l'accès natif SQL Server ('normal' pas celui pour pocket) sur
des applis 9, sans souci majeur. >En plus il n'est pas cher il en faut
seulement 1 par serveur, le nombre d'utilisateurs est illimité
tout est relatif, pour 1 client ayant 1 serveur oui
pour un groupe de magasin une centrale avec 200 magasins l'investissement
est consequant (200 * 800 = 160 000?. de plus quant on change le programme a
un client alors que tout fonctionnait sur l'ancienne, il ne veut pas
forcement investir c'est ce qui ce passe chez nous nous avons 1000 magasins
donc tu vois le cout pour SQLserver, nous avons choisi une base gratuite (HF
pour certain ou SQLite, MySQL a leur choix ) du fait que le client choisisse
ca base rend l'ensemeble gratuit HF biensur en standard MySQL, car le
programme se connecte a plusieurs bases et c'est le client final qui choisi
|
| |
| |
| | | |
|
| | |
| |
Posté le 13 février 2006 - 13:06 |
l'accés natif a été fait par souci de satisfaction des développeurs, et amélioration de la productivité. imaginez que vous avez réaliser une application qui fonctionne sous hyperfile, et puis vos client vous demande de migrer vers sql server ou oracle.
calculez l'investissement que vous devez faire pour refaire le code!!
et d'ailleurs je pense que la license n'est pas chere, vous pouvez la rajouter sur les devis de vos clients. |
| |
| |
| | | |
|
| | |
| |
Posté le 13 février 2006 - 14:44 |
Juste une question : est-ce bien utile de récupérer la totalité des enregistrements ? 100,000 lignes dans une table, çà me parait quand même beaucoup. Quel est le but de cette table ( outil de recherche/selection, impression d'un état...) ?
Dans l'application que je développe pour ma boite, j'ai "contourné" ce genre de problème:
1. l'utilisateur entre ses critères de recherche ( 43 critères actuellement )
2. Je lance une recherche dans la base via des requêtes SQL, et je récupère les enregistrements correspondant dans des fichiers HF temporaires
3. J'affiche les informations dans des tables fichiers, liés à ces fichiers HF
4. Une fois que l'utilisateur valide ces modifications, je retransfère les données dans la base via des requêtes SQL.
Mes critères sont pour la plupart des combos, qui sont "chargées" lors de la première "entrée" dans le champs. Pour information, la plus grosse ( 13200 lignes de type code + libelle), ne met qu'une seconde à se charger. Dans le cas des autres combos, le chargement est totalement imperceptible.
J'utilise des fichiers HF temporaires car j'ai des tables liées, et c'est beaucoup plus simple à faire avec des tables fichiers qu'avec des tables mémoires. De plus, comme la structure des fichiers dépend de données provenant de la base, je ne connais pas d'avance la liste des champs. Par exemple, quand j'affiche les encours de stock, j'ai une ligne par produit, et une colonne par stock. Or je ne connais la liste des stocks qu'au lancement de l'application.
Je connais une autre application ( pas développée en Windev ), dans laquelle les développeurs ont utilisé la méthode suivante:
Le but est de permettre à un utilisateur de rechercher un produit dans la base. L'utilisateur entre ces critères, et l'application charge les produits dans une tabe par paquet de 100. Un bouton permet à l'utilisateur de rechercher les 100 produits suivants, jusqu'à chargement complet de la table. Ce genre de "comportement" est assez facile à refaire avec les ordres SQL*, et correspond à peu près au fetch partiel de Windev.
Frédéric. |
| |
| |
| | | |
|
| | |
| |
Posté le 13 février 2006 - 16:04 |
C'est vrai que ma question est stupide vu comme ça, en général si on consulte une table de 100'000 enregistrements, y'aurait presque intérêt à avoir un minimum de critère de sélection pour trouver ce qui nous intéresse...
Je dois reconsidérer mon opinion moi aussi.
Merci encore de ton avis. |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|