Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement WinDev WD8 - Hyperfile vers SGBDR

WD8 - Hyperfile vers SGBDR

21 réponses
Avatar
I.G.LOG
Bonjour,
Devant les lenteurs que nous rencontrons avec WD8/HF7, nous envisageons
d'abandonner HF pour un SGBDR du marché type MySQL, Oracle, SQLServer...
Quels conseils pouvez-vous nous donner concernant :
1/ SGBDR: Le meilleur compromis coût (achat/administration), performances
et intégration à Windev
2/ Le mode de programmation si nous basculons vers ce SGBDR (je pense
notamment qu'on ne dispose plus des tables fichiers, des commandes
FichierVersEcran etc... et que ça va nécessiter un gros travail ?!)
Merci à tous
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3
Avatar
mat
Manu wrote:
Désolé mais quand je vois ta requete je comprends maintenant les personnes
qui pensent qu'avec une requete on peut tout résoudre :-(



Bonjour Manu,
C'est encore une particularité de HF7: une seule requête est beaucoup
plus vite que des requêtes enchaînées. Avec d'autres BD je faisais
plusieures étappes pour arriver à un tel résultat. Borland disait
toujours: des petites requêtes enchainées sont plus rapides qu'une seule
requête monstrueuse. Seulement, ici on a à voir avec PCS et sur HF7 ceci
donne des performances lamentables. Ce qui est triste de la part de PCS
était de dire aux clients: "...aucun problème, la migration de 5.5 à
7.5/8 se fait prèsque toute seule..." ou "...la 8 résoud tout les
problèmes...". Je n'ai plus touchés à mes applis 5.5 quand j'ai vu les
premières problèmes de migration. A mon avis il faut totalement repenser
un projet.
Avatar
I.G.LOG
> select O.OLCLEUNIK, O.TYPEPRE, L.NUMERO from OL O, PRESTAT P,
OLPROLG L left outer join ARTICLES A on (A.ARCLEUNIK = L.ARCLEUNIK)
where O.TERMINE = 0
and (L.OLCLEUNIK = O.OLCLEUNIK and L.NUMGRP = 128 and L.NUMPHA = 124 and
L.NUMCONTROLE = O.NUMCONTROLE)
and (P.PRCLEUNIK = L.NUMERO)
-> fonctionne


je voulais dire retourne bien les valeurs attendues (notamment les tuples
OLPROLG.ARCLEUNIK=0)


select O.OLCLEUNIK, O.TYPEPRE, L.NUMERO from OL O, PRESTAT P,
OLPROLG L left outer join ARTICLES A on (A.ARCLEUNIK = L.ARCLEUNIK),
ARTICLES left outer join FAMILLE C on (C.NUMCAT = A.NUMCAT and C.NUMFAM > A.NUMFAM)
where O.TERMINE = 0
and (L.OLCLEUNIK = O.OLCLEUNIK and L.NUMGRP = 128 and L.NUMPHA = 124 and
L.NUMCONTROLE = O.NUMCONTROLE)
and (P.PRCLEUNIK = L.NUMERO)


Ne retourne pas les valeurs attendues: ne renvoie pas les tuples
OLPROLG.ARCLEUNIK=0
Ce que je voulais: dans le cas OLPROLG.ARCLEUNIK=0 c'est que c'est un
dossier de négoce sans article principal et je le veux qd meme dans la liste
des travaux en cours. Dans le cas ou OLPROLG.ARCLEUNIK<>0, c'est un travail
de reparation sur un article principal et je veux sa famille (mais il n'a
pas forcemment de famille d'ou le ARTICLES left outer join...). Eh bien
cette requete ne me renvoi pas les OLPROLG ayant ARCLEUNIK=0 !!!!!????
Avatar
mat
I.G.LOG wrote:

L'application n'utilise pas - pour l'instant - d'accès SQL mais des ordres
H* et des vues. Les performances se sont degradees avec la migration vers
WD8 sans avoir modifie les methodes d'acces aux fichiers.
Les exemples de code SQL que j'avais transmis etaient destines a l'edition
des etats.



J'ai entendu qu'il y a des problèmes de ralentissements avec les filtres
, mais je n'ai rien à reprocher à la vitesse des commands H...
Les vues je les avais utilisées sous WD5.5 mais dans nos tests avec WD
7.5 elles n'étaient pas plus vite que les requêtes. Alors nous nous
sommes décidés pour les requêtes puisque l'usage est plus simple. Il y a
pourtant des gens pour qui disent que pour eux, les vues travaillent mieux.

select O.OLCLEUNIK, O.TYPEPRE, L.NUMERO from OL O, PRESTAT P,
OLPROLG L left outer join ARTICLES A on (A.ARCLEUNIK = L.ARCLEUNIK)
where O.TERMINE = 0
and (L.OLCLEUNIK = O.OLCLEUNIK and L.NUMGRP = 128 and L.NUMPHA = 124 and
L.NUMCONTROLE = O.NUMCONTROLE)
and (P.PRCLEUNIK = L.NUMERO)
-> fonctionne
Unquote...

Ce code n'est pas optimal pour HF7 car il combine une jointure par OUTER
JOIN et un autre par WHERE. Pour une meilleure performance, il ne faut
pas utiliser WHERE pour les jointures lorsqu'il y en a plusieurs.
Ensuite, d'abord joindre, après appliquer les conditions.





?! je ne vois pas comment construire cette requete autrement (je ne suis pas
un specialiste je l'avoue). Je veux tous tuples de OL non termines qui ont
un tuple OLPROLG (satisfaisant a la condition NUMGRP et NUMPHA) y compris
ceux dont OLPROLG.ARCLEUNIK=0 !?



Je ne suis non plus un expert SQL, mais pour avoir des résultat
acceptables il faut s'occuper du code.

Il n'y a pas de liaiason entre L et O, repésenté dans le WHERE avec
NumControle, et non plus pour les fichiers P et L. Le suivant devrait
correspondre à ton code et être conforme avec les "préférences" de HF7:

FROM OLPROLG L LEFT OUTER JOIN ARTICLES A ON (A.ARCLEUNIK = L.ARCLEUNIK),
OL O INNER JOIN L ON O.NumControle = L.Numcontrole,
PRESTAT P INNER JOIN L ON P.PrCleUnik = L.Numero
WHERE O.Termine = 0 AND L.NumGrp = 128 AND L.NumPha = 124

... donc d'abord les JOIN, après les WHERE...
pour le reste, il faut souvent faire plusieures essais avec le
positionnement des fichiers dans l'instruction SQL. Je n'ai pas été
capable de trouver des règles claires à suivre.


Je ne comprends pas "jointures externes chainées", mais ...




Ce que j'entend par jointure chainees: OLPROLG left outer join ARTICLES et
ARTICLES left outer join ... (nota: je crois que cette requete fonctionnait
avec HF5)



OK, il faut renommer le fichier, comme j'ai fait avec Address dans mon
exemple.



"FROM Invoice INNER JOIN InvoiceDetail ON Invoice.IDInvoice >>InvoiceDetail.IDInvoice, "+...



je vais etudier ce code... mais je croyais que le right outer join n'etait
pas supprote par WD8



RIGHT OUTER JOIN fonctionne depuis longtemps dans WD7.5 et ça
m'étonnerais qu'ils l'auraient enlevé dans la 8. D'autre part, pour des
cas pareils, on peut changer le tout dans les LEFT OUTER JOIN, suffit de
changer la position des fichiers.

En ce qui concerne des OUTER JOIN, j'ai tendance à ne les faire que dans
une direction, donc que des LEFT ou des RIGHT. Peut-être pas important,
mais il y a tellement de ponderables avec les requêtes...

Bonne chance.
Avatar
I.G.LOG
Après essais:

select O.OLCLEUNIK, O.TYPEPRE, P.PRCLEUNIK from PRESTAT P,
OL O inner join OLPROLG L on (O.NumControle = L.Numcontrole and L.NumGrp 128 AND L.NumPha = 124),
OLPROLG L left outer join ARTICLES A on (A.ARCLEUNIK = L.ARCLEUNIK),
PRESTAT P inner join OLPROLG L on P.PrCleUnik = L.Numero
WHERE O.Termine = 0
-> temps d'exécution infini ?! (j'ai arrete apres 30 secondes)

select O.OLCLEUNIK, O.TYPEPRE, L.NUMERO from OL O, PRESTAT P,
OLPROLG L left outer join ARTICLES A on (A.ARCLEUNIK = L.ARCLEUNIK)
where O.TERMINE = 0
and (L.OLCLEUNIK = O.OLCLEUNIK and L.NUMGRP = 128 and L.NUMPHA = 124 and
L.NUMCONTROLE = O.NUMCONTROLE)
and (P.PRCLEUNIK = L.NUMERO)
-> s'exécute en 4s56 (ce qui est beaucoup trop d'ailleurs)

Merci de t'etre penche sur le probleme
Phil

"mat" a écrit dans le message de
news:40d06244$
I.G.LOG wrote:

> L'application n'utilise pas - pour l'instant - d'accès SQL mais des


ordres
> H* et des vues. Les performances se sont degradees avec la migration


vers
> WD8 sans avoir modifie les methodes d'acces aux fichiers.
> Les exemples de code SQL que j'avais transmis etaient destines a


l'edition
> des etats.

J'ai entendu qu'il y a des problèmes de ralentissements avec les filtres
, mais je n'ai rien à reprocher à la vitesse des commands H...
Les vues je les avais utilisées sous WD5.5 mais dans nos tests avec WD
7.5 elles n'étaient pas plus vite que les requêtes. Alors nous nous
sommes décidés pour les requêtes puisque l'usage est plus simple. Il y a
pourtant des gens pour qui disent que pour eux, les vues travaillent


mieux.

>>select O.OLCLEUNIK, O.TYPEPRE, L.NUMERO from OL O, PRESTAT P,
>>OLPROLG L left outer join ARTICLES A on (A.ARCLEUNIK = L.ARCLEUNIK)
>>where O.TERMINE = 0
>>and (L.OLCLEUNIK = O.OLCLEUNIK and L.NUMGRP = 128 and L.NUMPHA = 124 and
>>L.NUMCONTROLE = O.NUMCONTROLE)
>>and (P.PRCLEUNIK = L.NUMERO)
>>-> fonctionne
>>Unquote...
>>
>>Ce code n'est pas optimal pour HF7 car il combine une jointure par OUTER
>>JOIN et un autre par WHERE. Pour une meilleure performance, il ne faut
>>pas utiliser WHERE pour les jointures lorsqu'il y en a plusieurs.
>>Ensuite, d'abord joindre, après appliquer les conditions.
>>
>
>
> ?! je ne vois pas comment construire cette requete autrement (je ne suis


pas
> un specialiste je l'avoue). Je veux tous tuples de OL non termines qui


ont
> un tuple OLPROLG (satisfaisant a la condition NUMGRP et NUMPHA) y


compris
> ceux dont OLPROLG.ARCLEUNIK=0 !?
>
Je ne suis non plus un expert SQL, mais pour avoir des résultat
acceptables il faut s'occuper du code.

Il n'y a pas de liaiason entre L et O, repésenté dans le WHERE avec
NumControle, et non plus pour les fichiers P et L. Le suivant devrait
correspondre à ton code et être conforme avec les "préférences" de HF7:

FROM OLPROLG L LEFT OUTER JOIN ARTICLES A ON (A.ARCLEUNIK = L.ARCLEUNIK),
OL O INNER JOIN L ON O.NumControle = L.Numcontrole,
PRESTAT P INNER JOIN L ON P.PrCleUnik = L.Numero
WHERE O.Termine = 0 AND L.NumGrp = 128 AND L.NumPha = 124

... donc d'abord les JOIN, après les WHERE...
pour le reste, il faut souvent faire plusieures essais avec le
positionnement des fichiers dans l'instruction SQL. Je n'ai pas été
capable de trouver des règles claires à suivre.

>>
>>Je ne comprends pas "jointures externes chainées", mais ...
>
>
> Ce que j'entend par jointure chainees: OLPROLG left outer join ARTICLES


et
> ARTICLES left outer join ... (nota: je crois que cette requete


fonctionnait
> avec HF5)

OK, il faut renommer le fichier, comme j'ai fait avec Address dans mon
exemple.

>
>
>>"FROM Invoice INNER JOIN InvoiceDetail ON Invoice.IDInvoice > >>InvoiceDetail.IDInvoice, "+...
>
> je vais etudier ce code... mais je croyais que le right outer join


n'etait
> pas supprote par WD8

RIGHT OUTER JOIN fonctionne depuis longtemps dans WD7.5 et ça
m'étonnerais qu'ils l'auraient enlevé dans la 8. D'autre part, pour des
cas pareils, on peut changer le tout dans les LEFT OUTER JOIN, suffit de
changer la position des fichiers.

En ce qui concerne des OUTER JOIN, j'ai tendance à ne les faire que dans
une direction, donc que des LEFT ou des RIGHT. Peut-être pas important,
mais il y a tellement de ponderables avec les requêtes...

Bonne chance.



Avatar
mat
I.G.LOG wrote:
Après essais:

select O.OLCLEUNIK, O.TYPEPRE, P.PRCLEUNIK from PRESTAT P,
OL O inner join OLPROLG L on (O.NumControle = L.Numcontrole and L.NumGrp > 128 AND L.NumPha = 124),
OLPROLG L left outer join ARTICLES A on (A.ARCLEUNIK = L.ARCLEUNIK),
PRESTAT P inner join OLPROLG L on P.PrCleUnik = L.Numero
WHERE O.Termine = 0
-> temps d'exécution infini ?! (j'ai arrete apres 30 secondes)

select O.OLCLEUNIK, O.TYPEPRE, L.NUMERO from OL O, PRESTAT P,
OLPROLG L left outer join ARTICLES A on (A.ARCLEUNIK = L.ARCLEUNIK)
where O.TERMINE = 0
and (L.OLCLEUNIK = O.OLCLEUNIK and L.NUMGRP = 128 and L.NUMPHA = 124 and
L.NUMCONTROLE = O.NUMCONTROLE)
and (P.PRCLEUNIK = L.NUMERO)
-> s'exécute en 4s56 (ce qui est beaucoup trop d'ailleurs)

Merci de t'etre penche sur le probleme
Phil




Ni l'un ni l'autre version correspond à ma recommendation. Mais bon,
laissons perdre... bonne chance.
Avatar
adrien
Je suis assez d'accord avec toi. J'ai migré des application de 5.5 vers 7.5 avec
quelques difficultés qui m'ont obligé a réécrire certains traitements.

Je ne le regrette pas aujourd'hui et la version 8 m'a permis de faire des mises
à jour payante de mon projet principal sans avoir passé beaucoup de temps de
developpement.

Je pense que la migration 5 vers 7 a été un mal bénéfique. Je regrette encore
moins aujourd'hui car j'ai des touches pour un projet sur pocket et je compte
bien sur la version que propose pc soft.

Certains de mes traitements sont probablement plus lents que si j'utilisais
d'autres SGBD mais vu le prix de déploiement, je ne me suis jamais lancé. Par
contre, mes applications n'ont rien a envier a des solutions plus à la mode
comme Java. Une de mes clients bosse dans le milieu bancaire et il m'a montré
une appli écrite en java. Je peux vous dire que mes projets windev avec hf sont
beaucoup plus performants !




--
Utilisez notre serveur de news 'news.foorum.com' depuis n'importe ou.
Plus d'info sur : http://nnrpinfo.go.foorum.fr/
Avatar
michel.chanu
mat wrote in message news:<40d05813$...
Manu wrote:
> Désolé mais quand je vois ta requete je comprends maintenant les personnes
> qui pensent qu'avec une requete on peut tout résoudre :-(

Bonjour Manu,
C'est encore une particularité de HF7: une seule requête est beaucoup
plus vite que des requêtes enchaînées. Avec d'autres BD je faisais
plusieures étappes pour arriver à un tel résultat. Borland disait
toujours: des petites requêtes enchainées sont plus rapides qu'une seule
requête monstrueuse. Seulement, ici on a à voir avec PCS et sur HF7 ceci
donne des performances lamentables. Ce qui est triste de la part de PCS
était de dire aux clients: "...aucun problème, la migration de 5.5 à
7.5/8 se fait prèsque toute seule..." ou "...la 8 résoud tout les
problèmes...". Je n'ai plus touchés à mes applis 5.5 quand j'ai vu les
premières problèmes de migration. A mon avis il faut totalement repenser
un projet.



Bonjour!

J'abonde dans le sens! Une appli basée en 5.5 n'a rien a voir avec une
appli en 7 et au dessus, surtout si l'analyse est relativement
complexe.

Un petit test m'a permis de vérifier cet état de fait sur des bases
issues de 5.5 voire 4.1. Si je ne migre pas toute l'analyse et les
fichiers d'une version à l'autre et ne refabrique pas les méthodes
et/ou procédures, les temps de réactions sur des requêtes (quelles
qu'elles soient) sont aberrants à pleurer (du genre il me faut 3
secondes en 5,5 et 3 minutes en 7,5).

Par contre, tout repenser avec les dernières fonctionnalités offertes
fonctionne bien mieux (du genre il me fallait 3 secondes en 5,5 et ça
ce fait en 1 seconde en 7,5... d'accord, j'ai bossé 1 semaine pour
obtenir ce résultat...), et là (ou las, comme on veut) le très gros
problème est que refaire un travail de plusieurs mois homme, les
clients n'aiment pas vraiment... (Pourtant je trouve ça rigolo pour ma
part...)

Je ne fais pas avancer le schmilblik, ce n'est qu'un état d'humeur.
Bon dev à toutes et tous.
Avatar
I.G.LOG
>
Par contre, tout repenser avec les dernières fonctionnalités offertes
fonctionne bien mieux (du genre il me fallait 3 secondes en 5,5 et ça
ce fait en 1 seconde en 7,5... d'accord, j'ai bossé 1 semaine pour
obtenir ce résultat...), et là (ou las, comme on veut) le très gros
problème est que refaire un travail de plusieurs mois homme, les
clients n'aiment pas vraiment... (Pourtant je trouve ça rigolo pour ma
part...)



je suis exactement dans ce cas: j'ai mis 6 mois à migrer ce projet et je me
demande combien de temps il me faudra encore pour retrouver des performances
correctes, au moins identiques a celles que j'avais avec WD5. Je n'ai pas
encore chiffré ces travaux ... et j'ai l'impression que mon client ne va pas
apprecier mes conclusions ! Et pourtant, pour les projets en cours de
developpement, est-ce une bonne strategie de rester en 5.5: version qui
n'est plus maintenue, fonctionnalites "depassees" etc, etc...
Avatar
Roumegou
I.G.LOG avait soumis l'idée :

Par contre, tout repenser avec les dernières fonctionnalités offertes
fonctionne bien mieux (du genre il me fallait 3 secondes en 5,5 et ça
ce fait en 1 seconde en 7,5... d'accord, j'ai bossé 1 semaine pour
obtenir ce résultat...), et là (ou las, comme on veut) le très gros
problème est que refaire un travail de plusieurs mois homme, les
clients n'aiment pas vraiment... (Pourtant je trouve ça rigolo pour ma
part...)



je suis exactement dans ce cas: j'ai mis 6 mois à migrer ce projet et je me
demande combien de temps il me faudra encore pour retrouver des performances
correctes, au moins identiques a celles que j'avais avec WD5. Je n'ai pas
encore chiffré ces travaux ... et j'ai l'impression que mon client ne va pas
apprecier mes conclusions ! Et pourtant, pour les projets en cours de
developpement, est-ce une bonne strategie de rester en 5.5: version qui
n'est plus maintenue, fonctionnalites "depassees" etc, etc...



Je suis passé directement de 5.5 à 7.5 et dans le cas d'une base de
données Oracle.
Je n'ai donc pas subit les pb de la V7, je n'ais eu aucun pb de
performance de bases de données puisque c'était Oracle.
Bref, une migration heureuse (non pas sans soucis mais c'était plus du
à l'obsolescence du code ou à des mauvaises codif) ; ce qui fait que je
trouve peu de défauts à WD75, ... mais je n'utilise pas HF.
J'ai quelque fois besoin de retourner en 5.5, quelle horreur !
Je pense pour ma part que l'on ne peut pas rester en 5.5 pour une appli
importante.

--
Eric Roumégou
http://cerbermail.com/?TSoulBerPA
(cliquez sur le lien ci-dessus pour me contacter en privé)
Avatar
jacques trepp
Roumegou wrote:
je trouve peu de défauts à WD75, ... mais je n'utilise pas HF.
J'ai quelque fois besoin de retourner en 5.5, quelle horreur !
Je pense pour ma part que l'on ne peut pas rester en 5.5 pour une
appli importante.


bonjour,
bien d'accord avec Eric. Windev 7.5 + Mysql (pour ma part) = programmeur
heureux :)
5.5 ... c'est vrai que quand il faut y retourner, c'est galère.
Mais quand il faut, il faut ;)


--
Jacques TREPP
AlbyGest


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.706 / Virus Database: 462 - Release Date: 14/06/2004
1 2 3