Discussion :

[luludev]

Bonjour,

Je vous sollicite aujourd'hui car j'aurais souhaité connaître les avantages et les inconvénients de l'accès natif payant proposé pour Windev par rapport à l'accès via OLE DB.

Si vous vous y connaissez à ce sujet, je serais bien content ...

[Lo²]

Bonjour,

Je n'ai pas testé car je trouve que l'utilisation de l'accès natif est cher... pour le client.

Ensuite, concernant les +, je dirais :
- vitesse d'accès (mais à vérifier)
- code d'accès à la base de données qui pourra être utilisé au cas où tu changes de base.

[vmolines]

- vitesse d'accès (mais à vérifier)

Donc pas à citer dans les +

- code d'accès à la base de données qui pourra être utilisé au cas où tu changes de base.

Pas forcément même en respectant toutes les indications de l'aide sur le sujet.

[Lo²]

En effet, j'ai mis la vitesse... par espoir

Pour le code, ça me déçoit mais il est vrai que j'utilise continuellement SQLExec avec les pilotes existants, donc ça ne me dérange pas plus que cela.

[Emmanuel Lecoester]

un accès sqlserver ne se fait pas en très bas niveau (comme les OCI pour Oracle), c'est quasiment du OLEDB optimisé donc je ne pense pas que la rapidité soit un critère très discriminant.

[vmolines]

Quand on voit le nombre de requêtes généré par l'accès natif MySQL (show columns) et la qualité des requêtes générées par l'accès natif Oracle (impossibilité d'utiliser un index sur un critère de filtre de date) , je doute que l'AN SQL Server soit plus rapide qu'OleDB.

Il faut arrêter de croire aveuglément les mérites vantés par les plaquettes commerciales.

[luludev]

... Il faut arrêter de croire aveuglément les mérites vantés par les plaquettes commerciales.

C'est un peu ce que je me dit aussi, ils vendent un accès natif qui n'a pas forcément un internet autre que commercial !

J'ai fait un prg de test, avec un accès OLE DB à une base SQL Server, les commande HLIT... fonctionne bien a priori même sur si prg de test ne fait qu'ajouter ou lire un enregistrement dans ma base !

[jakkson007]

Bonjour,

Nous avons fait quelques tests de performance avec le DLL acces natif de Windev pour MS-SQL. A notre grande surprise nous avons constaté que celui-ci est beaucoup plus lent que par OLE DB...


Temps en centièmes de seconde


Test 1 - Exécution d’un requête du projet (HExécuteRequête) et affichage d’une table fichier liée à la requête (Table..fichierParcouru = REQ)

Execution de la requete acces natif 23 centiemes
Execution de la requete OLE DB 3 centiemes
Affichage de la table acces natif 23 centiemes
Affichage de la table OLE DB 2 centiemes


Test 2 – Exécution d’une requête SQL (HExécuteRequêteSQL) et affichage d’une table mémoire (HLitPremier,HlitSuivant,TableAjouteLigne)

Execution de la requete acces natif 22 centiemes
Execution de la requete OLE DB 1 centiemes
Affichage de la table acces natif 34 centiemes
Affichage de la table OLE DB 14 centiemes


Test 3 – Lecture du fichier et affichage d’une table mémoire (HLitPremier,HlitSuivant,TableAjouteLigne)

Affichage de la table acces natif 36 centiemes
Affichage de la table OLE DB 14 centiemes

[luludev]

Effectivement (jakkson007), c'est très intéressant ...

[Ry_Yo]

Pour apporter le peu d'expérience que j'ai sur le sujet, on a poussé quelques test de notre côté (dans le cadre d'une migration de HF vers SQL Server)... l'accès natif était donc à priori selon "les plaquettes PCSoft" le plus adapté en terme de coût...

En fait pour analyser les perf. on s'est surtout basé sur le profiler de MS-Sql et l'analyseur de perf. de Windev. (AN WD14 et MS-SqlServeur 2005)

Résultat :
L'éxécution d'une requête est plus rapide en AN, par contre c'est l'ouverture et la fermeture de requête qui est plus longue...
Histoire de citer l'exemple incriminé dans notre test... une boucle de parcours d'une table mémoire d'ID (POUR i=1 A...) et pour chaque ID recherche dans la base du nom client... (HLitRecherche....)
L'éxécution pure de la requête moins d'une seconde et même légèrement plus rapide qu'ODBC ou OLEDB...
Par contre temps de déclarer et fermer la requête relativement long...

Tps ExecAN < Tps ExecOLE
Tps OpenAN + Tps ExecAN + Tps CloseAN > Tps OpenOLE + Tps ExecOLE + Tps CloseOLE

Si on reprend mon exemple avec des chiffres (qui ne reflète pas la réalité des mesures mais un ordre de grandeur) :

0.5 sec. < 1 sec.
1 sec. + 0.5 sec. + 1sec. > 0.5 sec. + 1 sec. + 0.5 sec.

On multiplie le tout par 100 par exemple...( car ma table mémoire contient 100 ID Client) :
on remplit notre table mémoire en 2500 sec. par AN Sql contre 2000 sec. pour OLE

Mais autre souci aussi (il paraît que ça s'est amélioré avec les derniers AN ??) c'est le rapatriement en mémoire des données avant traitement... en gros cela veut dire que vous faites un SELECT sur un ID Client précis, l'AN va quand même rapatrier en mémoire toute la table Client, puis une fois en local va traiter le WHERE... Donc si votre base se trouve sur un mauvais réseau... les temps de traitement sont encore plus dégradé...

Autre souci aussi, le nombre de requête que génère l'AN... étant donné que c'est une surcouche... le HLitsuivant(ID) est transformé pour SQL Server en SELECT .... FROM ... WHERE ID > IDEnCours ORDER BY ID.... !!!
Donc imaginé un peu votre parcours... Je rapatrie TOUT en mémoire ordonné par l'ID de parcours pour connaitre le suivant...
( Pour les sceptiques, un coup de profiler pour le voir de vos yeux)

Bref... l'AN pour moi n'est pas conseillé pour une migration de HF vers SQL Server... après peut-être que selon la volumétrie et surtout la manière dont le développeur a écrit ses algo de CRUD (Create/Read/Update/Delete) ça peut passer... mais j'en doute...

Si migration doit-être faite... autant basculer en HF C/S c'est plus sûr et plus rapide..

Voilà mon avis perso.

[luludev]

Je reviens sur cette discussion après avoir discuté avec un chef de projet qui utilise Windev et SQLServer.

En fait chez eux, pour une question de performance, il utilise Windev sans analyse et travaille uniquement avec la fonction SQLExec() pour toutes les actions sur la base (Select, Insert, ...).
A mes yeux cela augmente considérablement le temps de développement mais chez eux c'est comme ça !

Qu'en pensez vous ?

[vmolines]

En clair, je déconseille fortement l'utilisation d'HF classic en réseau et d'ailleurs je déconseille l'utilisation d'HF tout cours. Je déconseille également l'utilisation de toutes les fonctions commençant par "HLit" et préconise l'utilisation du SQL qui à défaut d'être plus performant permet de ne pas oublier ce langage fondamental (en clair ne pas perdre de compétences), le tout avec une BDD standard du marché (MySQL, SQLLite, MS SQL Serveur, etc ...), tout sauf Access ou HF.

source : http://www.developpez.net/forums/d77...v/#post4572342

Pour conclure, je vais me répéter. N'utilisez JAMAIS l'accès aux données de Windev si vous travaillez sur un projet sérieux (exit l'analyse, les ordres H, les requêtes Windev).

source : http://www.developpez.net/forums/d94...bases-donnees/

Aucune de mes applications n'a d'analyse, pour éviter les synchros "hazardeuses". Tout passe par des requêtes SQL et une connexion ODBC (sans problème de performances !).

source : http://www.developpez.net/forums/d77...v/#post4572599

Quant à l'analyse elle me sert juste à avoir la liste des fichiers/rubriques sous les yeux (pour le F11, le drag & drop etc ...) mais je pourrais m'en passer

source : http://www.developpez.net/forums/d10...s/#post5624296

A mes yeux cela augmente considérablement le temps de développement ...

En quoi cela augmenterait les temps de dev selon vous ?

[dsr57]

J'ajouterais un inconvénient de l'accès natif, c'est que à chaque achat de nouvelle version de Windev, tu dois repasser aussi à la caisse pour l'accès natif.

[Hibernatus34]

Bonjour,

Si vous êtes malin et rigoureux, vous pouvez avoir le meilleur des 2 mondes.
Ici, nous utilisons SQL Server via OLE DB, avec :
- L'analyse et tout ce que ça permet de faire dans le code (complétion, lisibilité, HAjoute, un HModifie maison...)
- Du SQL complexe (PARTITION BY, fonctions scalaires, etc. sans avoir peur que ça ne soit pas supporté comme avec HF), parfois avec des blocs de code déclarant des variables locales qu'OLE DB ne permet normalement pas d'exécuter, et avec la récupération de valeurs de retour
- Les mêmes performances que du SQLExec
- Un système de mise à jour du schéma d'après l'analyse complètement automatique au lancement de l'application
- Des requêtes paramétrées ayant la même syntaxe que les accès natifs ("sdSource.Param = 42" avant l'exécution de la requête, et "Toto = @Param" dans le code SQL)
- Un palliatif transparent au problème des sources de données dont le nom a une portée globale (elles sont rendues uniques dans notre surcharge de HExécuteRequête)
- La possibilité d'exécuter des requêtes en curseur client (bien plus rapide pour INSERT, DELETE et UPDATE)
- Tables temporaires (#MaTable) également décrites dans l'analyse
- Génération de code SQL d'après des clé composées : pousse naturellement le développeur à faire des requêtes optimisées pour les index. Par exemple : génération de la clause ORDER BY, d'une comparaison de tuple (BETWEEN d'une clé composée "index friendly")...
- etc.

Je ne peux pas partager tout ça car ça appartient à mon client.
Mais c'est pour vous dire qu'on peut le faire.
Dans notre cas il fallait convertir un projet énorme de HF vers SQL Server, et cette approche nous a fait gagner énormément de temps car on n'a pas eu a écrire des requêtes pour tout, car ayant les infos de l'analyse on a pu écrire beaucoup de fonction qui génèrent les requêtes les plus courantes à partir de noms de fichiers et de rubriques. Et ces noms sont passés "sans les guillemets" ce qui nous fait un code aussi limpide et propre que du HF.

[vmolines]

Bonjour,

Si vous êtes malin et rigoureux, vous pouvez avoir le meilleur des 2 mondes.
Ici, nous utilisons SQL Server via OLE DB, avec :
- L'analyse et tout ce que ça permet de faire dans le code (complétion, lisibilité, HAjoute, un HModifie maison...)
- Du SQL complexe (PARTITION BY, fonctions scalaires, etc. sans avoir peur que ça ne soit pas supporté comme avec HF), parfois avec des blocs de code déclarant des variables locales qu'OLE DB ne permet normalement pas d'exécuter, et avec la récupération de valeurs de retour
- Les mêmes performances que du SQLExec
- Un système de mise à jour du schéma d'après l'analyse complètement automatique au lancement de l'application
- Des requêtes paramétrées ayant la même syntaxe que les accès natifs ("sdSource.Param = 42" avant l'exécution de la requête, et "Toto = @Param" dans le code SQL)
- Un palliatif transparent au problème des sources de données dont le nom a une portée globale (elles sont rendues uniques dans notre surcharge de HExécuteRequête)
- La possibilité d'exécuter des requêtes en curseur client (bien plus rapide pour INSERT, DELETE et UPDATE)
- etc.

Je ne peux pas partager tout ça car ça appartient à mon client.
Mais c'est pour vous dire qu'on peut le faire.
Dans notre cas il fallait convertir un projet énorme de HF vers SQL Server, et cette approche nous a fait gagner énormément de temps car on n'a pas eu a écrire des requêtes pour tout, car ayant les infos de l'analyse on a pu écrire beaucoup de fonction qui génèrent les requêtes les plus courantes à partir de noms de fichiers et de rubriques. Et ces noms sont passés "sans les guillemets" ce qui nous fait un code aussi limpide et propre que du HF.

Vous avez redéfini le HAjoute mais celui ci ne contient plus le WL.HAjoute, j'ai bien compris ?

Je peux comprendre la volonté de conserver l'analyse d'un point de vue référentiel (schéma, complétion, ...) mais on est d'accord vous n'utilisez pas la couche d'accès à la base de données Windev/H et il y a des SQLExec derrière toutes vos redéfinitions ?

[Hibernatus34]

En réalité, le HAjoute est la seule fonction de modif que nous avons gardée.
Elle a toujours bien fonctionné et permet de récupérer l'identifiant auto facilement.

On utilise toujours HLitRecherchePremier pour lire un enreg et afficher sa fiche par exemple, mais une version à nous qui force hLimiteParcours et avec une syntaxe un peu plus légère (HLitRech(Fichier.RubriqueClé, ValCompante1, ValComposante2...) sans crochets).
On ne fait aucun parcours sur fichier, ni HSupprime, HFiltre, HModifie...

On aurait pu utiliser le HModifie sur requête (en curseur serveur ça reporte les modifs sur les fichiers d'origine), mais on a voulu rester simple et on ne fait que des UPDATE (souvent via des fonctions comme notre surcharge de HModifie ou une fonction du genre ModifVal(Fichier.Rubrique, Valeur, Fichier.Clé, ValeurClé, *) quand c'est une modif isolée)

[luludev]

En quoi cela augmenterait les temps de dev selon vous ?

complétion
lisibilité
utilisation des fonctions HXXX

Mise à jour automatique de la base de données lors du déploiement

etc...

[vmolines]

complétion
lisibilité
utilisation des fonctions HXXX

Mise à jour automatique de la base de données lors du déploiement

etc...

Complétion => en effet ça réduit le temps de dev (mais pensez-vous que le temps passé à écrire le nom d'une colonne est significatif sur le temps d'un projet ?)
Lisibilité => discutable
utilisation des fonctions HXXX => en quoi cela fait gagner du temps par rapport aux fonctions SQLXXX par exemple?
Mise à jour automatique de la base de données lors du déploiement => c'est beau d'avoir confiance

[Hibernatus34]

Complétion => en effet ça fait augmenter le temps de dev
Lisibilité => discutable
utilisation des fonctions HXXX => en quoi cela fait gagner du temps par rapport aux fonctions SQLXXX par exemple?
Mise à jour automatique de la base de données lors du déploiement => c'est beau d'avoir confiance

Je ne connais pas très bien SQLExec, mais il me semble qu'on ne peut pas écrire du code aussi clair que l'exemple suivant avec, si ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
sSQL est chaîne = [
SELECT
	Col1,
	Col2
FROM
	toto
WHERE
	titi = @Param1
]
sdReq est une source de données
 
sdReq.Param1 = "toto"	// Paramètres nommés, sans guillemets
// Basé sur HExécuteRequêteSQL :
SI ExécuteRequête(sdReq, sSQL) ALORS
	// Parcours simplifié
	POUR TOUT sdReq
		// Colonnes nommées, sans guillemets
		Trace(sdReq.Col1, sdReq.Col2)
	FIN
FIN
// Pas de code de libération de ressource, c'est implicite

J'avoue que dans la pratique je n'utilise pas "POUR TOUT" car il fait un HLitPremier sans l'option hSansRafraîchir, ce qui est rédhibitoire dans le cas d'une requête en curseur client.
Et pour les sources de données il a fallu ruser pour corriger le fait que WinDev les gère via un identifiant global.
Enfin, les paramètres nommés ne sont gérés qu'en accès natif normalement, c'est nous qui avons rajouté cette fonctionnalité à l'accès OLE DB.

Quel serait le code équivalent avec SQLExec ?

Concernant la mise à jour auto, ça n'existe que pour HF, donc la question ne se pose pas ici. Nous l'avons développée pour SQL Server via OLE DB et nous l'exécutons au démarrage de l'application, ce qui est plus pratique qu'à l'installation. Ça marche super bien jusqu'ici, on a gagné beaucoup de temps.
Celle de HF est mauvaise car si on rajoute des contraintes il ne s'assure pas qu'elles sont respectées, on peut donc avoir une clé unique avec des doublons par exemple. En SQL Server c'est pas possible donc on gère ça différemment.

[Lo²]

Bonjour,

Un équivalent SQLExec :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
sSQL est chaîne = [
SELECT
Col1,
Col2
FROM
toto
WHERE
titi = %1
]
monParam est chaîne = "toto"
 
SI SQLExec("RST", ChaîneConstruit(sSQL, monParam)) ALORS
	SQLPremier("RST")
	TANTQUE PAS SQL.EnDehors
		Trace(SQLCol("RST", 1), SQLCol("RST", 2))
 
		SQLSuivant("RST")
	FIN
	SQLFerme("RST")	
FIN
 
//OU
 
SI SQLExec("RST", ChaîneConstruit(sSQL, monParam)) ALORS
	TANTQUE SQLAvance("RST") = 0
		Trace(SQLLitCol("RST", 1), SQLLitCol("RST", 2))
	FIN
	SQLFerme("RST")
FIN

Le premier cas permet de lire plusieurs fois la valeur d'une colonne, mais tous les résultats sont en mémoire.
Le deuxième ne permet de lire qu'une fois la colonne et les résultats sont remontés ligne à ligne.