Discussion :

[vmolines]

Bonsoir,

Petit sujet coup de gueule en ce vendredi soir. Vous me savez critique envers la gestion de l'accès aux données de PCSoft que je qualifie souvent de buggée, approximative ou mensongère.

Me voici avec un nouvel exemple sous la main. Je plante le décor avec un besoin courant, gérer des périodes, une base Oracle (accès natif) et l'envie d'utiliser les outils fournis dans les règles de l'art.

Pour ça je créée une simple table dans l'analyse (chère analyse ...) :

IDPeriode Entier
DateDebut DateHeure
DateFin DateHeure

Les deux bornes étant indexées indépendamment (je voulais voir après pour les optimisations)


Je demande la création des scripts, cette fois ci ça se passe bien :

Code :

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

1
2
3
4
5
6
CREATE TABLE TestDate (
    IDTestDate NUMERIC(10,0)  PRIMARY KEY ,
    DateDebut DATE ,
    DateFin DATE );
CREATE INDEX WDIDX_TestDate_DateDebut ON TestDate (DateDebut);
CREATE INDEX WDIDX_TestDate_DateFin ON TestDate (DateFin);

Pour le fun, je teste un HCreationSiInexistant, idem, ça sort bien.


L'utilisation maintenant. Je mets de côté mes convictions et fais une requête dans l'éditeur de requêtes qui donne ça :

Code :

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

1
2
3
4
5
6
7
SELECT 
	TestDate.IDTestDate AS IDTestDate,	
	TestDate.DateDebut AS DateTest
FROM 
	TestDate
WHERE 
	TestDate.DateDebut = {pdhDateHeure}

pdh car je compte fournir un paramètre de type DateHeure et éviter ainsi toute méprise de type aux yeux du moteur de requêtes.

Je jette quelques données dans la table avec deux périodes (02/07/2010 00:00:00 à 03/07/2010 00:00:00, 02/08/2010 00:00:00 à 04/08/2010 00:00:00):

Code :

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

1
2
INSERT INTO TESTDATE (IDTESTDATE, DATEDEBUT, DATEFIN) VALUES (1, TO_DATE('2010-07-02 00:00:00', 'YYYY-MM-DD HH24:MI:SS'), TO_DATE('2010-07-03 00:00:00', 'YYYY-MM-DD HH24:MI:SS')) ;
INSERT INTO TESTDATE (IDTESTDATE, DATEDEBUT, DATEFIN) VALUES (2, TO_DATE('2010-08-02 00:00:00', 'YYYY-MM-DD HH24:MI:SS'), TO_DATE('2010-08-04 00:00:00', 'YYYY-MM-DD HH24:MI:SS')) ;

Je me lance avec le code suivant :

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
dhDateHeure est un DateHeure
 
dhDateHeure..Année = 2010
dhDateHeure..Mois = 7
dhDateHeure..Jour = 25
dhDateHeure..Heure = 0
dhDateHeure..Minute = 0
dhDateHeure..Seconde = 0
dhDateHeure..Milliseconde = 0
 
ReqDate.pdhDateHeure = dhDateHeure
HExécuteRequête(ReqDate)
POUR TOUT ReqDate
	Trace(ReqDate.IDTestDate, ReqDate.DateDebut)
FIN
HAnnuleDéclaration(ReqDate)

La trace affiche ... Roulement de tambour ...

Code :

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

1 20100702000000000

Bon ça fonctionne . Alors quel est mon problème si ça retourne le bon résultat ? Pour ça il faut regarder le log de requêtes d'Oracle pour voir ce que Webdev a envoyé à mon cher SGBD, et voici le résultat :

Code :

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

1
2
3
SELECT TestDate.IDTestDate  AS IDTestDate , TestDate.DateDebut  AS DateTest 
FROM TestDate  
WHERE  ( TO_CHAR(TestDate.DateDebut,'YYYYMMDDHH24MISS') = :1 )

Pour ceux qui ne seraient pas habitués, le :1 est un paramètre Oracle qui reçoit "20100702000000000". Je ne compare pas ma colonne DateDebut mais un TO_CHAR(TestDate.DateDebut). Les conséquences sont désastreuses car tout index posé sur la rubrique DateDebut ne sera jamais utilisé car la comparaison n'est pas faite directement avec la colonne. Pour information, la bonne pratique SQL est de comparer la colonne à un TO_DATE de la chaîne qui représente la date que je cherche.

Le comble, le clou du spectacle, appelez ça comme vous voulez, c'est que si je supprime l'index dans l'analyse, l'optimiseur de requête (ahem !) me dit que je gagnerai en performance avec un index sur DateDebut . Mais très cher, si tu savais t'en servir, peut être qu'on gagnerait en performance.

Cet exemple parmi d'autres est une preuve flagrante de l'amateurisme quelquefois constaté quand on regarde en détail comment l'accès au données a été développé. Et je persiste, "Amateurisme" car la personne qui a développé le moteur de conversion SQL Windev -> SQL Oracle a sciemment traité la conversion de la colonne plutôt que la conversion du paramètre. Quelle question s'est il posé à ce moment là ? Je me le demande. Soit il ne sait pas comment travaille une base de données avec les indexes ; très grave quand on est en charge de traiter le moteur de conversion SQL. Soit il le sait mais n'en a pas tenu rigueur ; encore plus grave.

Alors vous me direz, c'est un bug, il suffit de le soumettre à PCSoft. Je suis las de remonter des bugs très précis à PCSoft pour lesquels je suis capable de fournir moi même un correctif. Cet exemple était destiné à être envoyé au ST mais il n'ira pas. J'ai déjà soumis des bugs bloquants du même genre sur l'accès aux données. Les réponses du ST : "Utilisez HRequêteSansCorrection". Sauf que dans la documentation, PCSoft mentionne "Performant ! Compatible toutes bases ! Epargnez vous les spécificités des bases de données ! Accès Natif Oracle ultra rapide xxxx € !". PCSoft ne fournira jamais de correctif pour la V14 alors qu'on frise la publicité mensongère (je suis gentil quand je dis "frise"). Je travaille sur un projet où les décideurs ont cru à ce discours et les pertes (temps et argent) occasionnées par ce type de problème sont grandes.

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). Personne n'a aujourd'hui produit de couche d'accès aux données à la fois simple à utiliser, performante et multi bases. L'utilisation correcte d'une base de données est tout sauf de l'approximation.

A bon entendeur

ps : sur ce je retourne à mon SQL pur
ps2 : note aux modérateurs, avant de faire quoi que ce soit avec ce sujet d'intérêt public, merci d'en discuter au préalable. J'ai bien choisi mes termes et mes exemples, il n'y a aucune calomnie.

[tatayo]

...
(exit l'analyse, les ordres H, les requêtes Windev)
...

Bienvenue au club, dont je suis membre depuis la Windev 10 !

Tatayo.

[SevenSoftware]

Bonjour,

Tout à fait d'accord avec vous.

J'utilise toujours HRequeteSansCorrection, que ce soit pour Oracle ou pour l'AS400. Les optimiseurs SQL de ces deux BdD sont très performants, c'est pas pour leur donner à manger des requêtes inoptimisables !

A+

[Emmanuel Lecoester]

en toute franchise, cela ne me choque pas plus que cela

Je travaille avec Oracle toute la journée et donc gérer des colonnes au format date cela arrive assez souvent

bien souvent on ne stocke que la date du jour dans une colonne de ce type donc pour vérifier on a deux méthodes :

Code :

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

To_char(macolonne,'YYYYMMDD') = :1

ou

Code :

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

macolonne = to_date(:1,'YYYYMMDD')

avec bien sur une préférence pour la deuxième écriture qui exploite l'index.

Je pense que l'éditeur va voir ce qu'il peut faire pour cela : il suffit de modifier l'ordre généré au niveau de l'API OCI

[vmolines]

en toute franchise, cela ne me choque pas plus que cela

Pas plus que cela ? Vous voulez dire : pas plus que d'habitude ? pas plus tout court ?

Je travaille avec Oracle toute la journée et donc gérer des colonnes au format date cela arrive assez souvent

bien souvent on ne stocke que la date du jour dans une colonne de ce type donc pour vérifier on a deux méthodes :

Code :

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

To_char(macolonne,'YYYYMMDD') = :1

ou

Code :

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

macolonne = to_date(:1,'YYYYMMDD')

avec bien sur une préférence pour la deuxième écriture qui exploite l'index.

Oui merci c'est ce que j'explique dans mon 1er post et ma critique porte sur le fait qu'une requête Windev ne permet pas d'avoir la requête correcte exécutée. Et pour me répéter, Windev est vendu comme un EDI avec accès multi base sans différencier le code. Cependant, rendre impossible l'utilisation des index sur les colonnes date sans raison valable est totalement innacceptable puisqu'il conduit soit :

- à des performances catastrophiques si on veut rester compatible multibases
- à une écriture spécifique des requêtes pour chaque base ce qui remet en cause le discours commercial si cher à PCSoft

Je pense que l'éditeur va voir ce qu'il peut faire pour cela : il suffit de modifier l'ordre généré au niveau de l'API OCI

Encore merci. En effet, "il suffit de" et ce que je critique c'est que l'éditeur ne le fasse pas quand je lui remonte ces bugs de manière précise et que l'aide de ma version indique que ce que je fais doit marcher (Cf. mon problème avec le Coalesce et les valeurs numériques).

Qu'est ce qui vous permet de dire que l'éditeur va voir ce qu'il va faire pour cela ? Pour l'instant je n'ai pas l'impression que PCSoft souhaite donner des correctifs pour que Windev fasse ce pour quoi il est vendu. Si vous avez des informations supplémentaires pour faire avancer des correctifs de bugs, je suis preneur.

[Emmanuel Lecoester]

Elle ne m'étonne pas plus outre mesure car beaucoup de ORM fonctionne comme cela... ce qui rend WinDev dans la moyenne...

Rien ne me dit que l'éditeur le fera (il suffit de voir leur gestion du timeout MySQL dans l'API éditeur, je ne sais pas si ils l'ont pris en compte alors que la réponse existe depuis 4-5 ans) .

Je vais jouer sur les mots tout en faisant mon avocat du diable (donc attention aux réactions) :

• Cette non gestion des index sur des champs date vous empêche-t-il de communiquer avec une base Oracle ? la réponse est bien sur NON.
• Cette non gestion des index sur des champs date vous a-t-elle fait modifier votre code ? la réponse est bien sur NON.
• Votre application pour Oracle est-elle optimisée pour cette gestion ? la réponse est NON et rien ne l'assure dans la documentation fournie.

Une API d'accès à un autre SGBD que HF est fourni en terme d'ouverture et en terme de notre EDI sait accéder à toutes la bases du marché. La puissance des accès natifs est bien de vous connecter une autre base que HF sans modifier une seule ligne de code. Ne vous attendez pas à plus .

[vmolines]

Je suis le premier à dire qu'un ORM, et plus précisément sa partie DAL, ne peut fournir à la fois un accès optimisé et universel aux SGBD. Cependant, dans mon exemple je pointais vraiment le manque de connaissance ou le déni et ne voulait pas élargir le débat aux problèmes inhérents aux ORM.

Le problème est bien de jouer sur les mots, de faire croire à un client mal averti que l'accès aux données PC Soft évite de se poser des questions. Je ne fais que contre balancer leur discours ou leurs non-dits qui pourraient laisser croire au miracle.

Concernant mon exemple sur les colonne date indexées, je dirai que j'ai du modifier mon code pour que ça fonctionne décemment. L'exemple du Coalesce (autre sujet du forum) par contre faisait planter mon application et m'a obligé à écrire du SQL spécifique alors que je restais dans les préconisations de toutes les documentations qui couvrent le sujet. Donc même en acceptant le double langage et les jeux de mots, ça ne fonctionne pas. La puissance des accès natifs n'est pas au rendez-vous.

Je me répète, je n'ai jamais attendu cela la part de l'éditeur mais il le propose et ne tient pas ses engagements.

[Emmanuel Lecoester]

Pour rebondir sur ta proposition, un benchmark serait utile sur l'accès aux données via les accès natifs. Histoire de mesurer les différences de temps entre un accès odbc , old-db, AN

[vmolines]

Pour rebondir sur ta proposition, un benchmark serait utile sur l'accès aux données via les accès natifs. Histoire de mesurer les différences de temps entre un accès odbc , old-db, AN

Ce serait intéressant mais sans rapport avec le présent sujet.

[Emmanuel Lecoester]

Ben si je trouve car en plus de la gestion des cast (ton cas), il a aussi la gestion des transactions, voir comment réagisse certaines analyse dans d'autres SGBD (les tableaux par exemple).

[Marco46]

On a eu des problèmes similaires sur l'accès natif SQLServer, sauf qu'au lieu d'ignorer les index ça crashait l'appli ! Ils doivent pas aimer les dates chez PCSoft ...

Par contre la correction de l'accès natif a été relativement rapide (quelques jours/semaines).

Ceci dit, ça fait pas très sérieux. Les décideurs sont de grands naïfs finalement, et pour leur expliquer qu'ils se sont fait avoir c'est compliqué. Pourtant il est assez simple de comprendre que si à chaque Hxxx il y a un ordre donné à la BDD derrière (par ex 2 boucles imbriquées pour une requête sur 3 tables), ça ne peut pas être plus rapide que de SQL normal. Et si on utilise du SQL normal, il faut bien adapter le code à l'implémentation de la BDD.

Donc croire la publicité de PCSoft à ce niveau ça confine à la bêtise si on sait un peu de quoi on parle.

VMolines tu bosses sur Webdev ? Que je te plains

[bombseb]

Bon ça fonctionne . Alors quel est mon problème si ça retourne le bon résultat ? Pour ça il faut regarder le log de requêtes d'Oracle pour voir ce que Webdev a envoyé à mon cher SGBD

Bonjour, j'utilise l'acces natif sybase et AS400, pouvez vous me dire ou se trouve ce fichier log svp ?

Pourtant il est assez simple de comprendre que si à chaque Hxxx il y a un ordre donné à la BDD derrière (par ex 2 boucles imbriquées pour une requête sur 3 tables), ça ne peut pas être plus rapide que de SQL normal

par exemple si je fait une boucle avec un HExecuteRequete et un HLitPremier avant et un HLitSuivant à la fin de la boucle, il envoie un ordre SQL pour chaque ligne ???
c'est grave là quand même....
vous confirmez ?

[vmolines]

L'existence, l'activiation et la consultation de logs de requêtes est spécifique à chaque SGBD, je ne connais pas sybase et AS400 pour vous indiquer la marche à suivre. Il vaudrait mieux se tourner vers le forum approprié.

Une requête ne génère pas plusieurs ordres SQL vers la base de données. C'est l'utilisation de parcours imbriqués dans le code qui conduit à celà. Exemple typique que je vois hélas trop souvent :

Code :

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

1
2
3
POUR TOUT TableA
HLitRecherchePremier(TableB, IDTableB, TableA.IDTableB)
FIN

Sans vouloir rentrer dans un débat sur l'incompétence en ce qui concerne la base de données et le SQL...

[Marco46]

par exemple si je fait une boucle avec un HExecuteRequete et un HLitPremier avant et un HLitSuivant à la fin de la boucle, il envoie un ordre SQL pour chaque ligne ???
c'est grave là quand même....
vous confirmez ?

Non je confirme pas. Je parlais des fonctions HLitxxx.

Par exemple :

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
 
HLitRecherche(TABLE_1,CLEF,VALEUR,hIdentique)
TANTQUE HTrouve(TABLE_1) ET PAS HEnDehors(TABLE_1)
 
        //Traitement
 
	HLitRecherche(TABLE_2,CLEF,TABLE_1.VALEUR,hIdentique)
	TANTQUE HTrouve(TABLE_2) ET PAS HEnDehors(TABLE_2)
 
		//Traitement
 
		HLitSuivant(TABLE_2,CLEF)
	FIN
 
	HLitSuivant(TABLE_1,CLEF)
FIN

Ce type de code est plus que fréquent dans les softs développés avec les ordres HLit. En terme de performance c'est une usine à gaz car chaque ordre HLitxxx déclenche un accès réseau. On a pas fait de tests précis à ce niveau, on voit juste facilement ça avec un sniffer réseau et des points d'arrêts dans le code.