Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
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
Florian B.
Pour rappel Hyper File est un SGBDR complet... tu dois vouloir basculer vers du
client/serveur et plus du séquentiel indexé... Dans ce cas pourquoi ne pas
attendre la version client/serveur de Hyper File ? PC SOFT aura certainement
fait en sortie que les traitements restent les mêmes, même si l'utilisation de
requêtes est toujours à privilégier en client/serveur par rapport à des lectures
enreg par enreg (Hyper File est inbatable là dessus).


A+




--
Utilisez notre serveur de news 'news.foorum.com' depuis n'importe ou.
Plus d'info sur : http://nnrpinfo.go.foorum.fr/
Avatar
I.G.LOG
Bonjour,
Le projet sur lequel je travaille a été migré de WD5.5 et WD8 et est devenu
inexploitable à cause des lenteurs HF7 (jusqu'à 20 fois + lent que
WD5.5/HF5). Les utilisateurs (le logiciel est en exploitation) ne pourront
pas attendre une "hypothétique" sortie de HF-client/serveur. Nous sommes
donc en train d'étudier le basculement vers un autre système de fichiers,
plus performant (MySQL ou autres)

"Florian B." a écrit dans le message de
news:



Pour rappel Hyper File est un SGBDR complet... tu dois vouloir basculer


vers du
client/serveur et plus du séquentiel indexé... Dans ce cas pourquoi ne pas
attendre la version client/serveur de Hyper File ? PC SOFT aura


certainement
fait en sortie que les traitements restent les mêmes, même si


l'utilisation de
requêtes est toujours à privilégier en client/serveur par rapport à des


lectures
enreg par enreg (Hyper File est inbatable là dessus).


A+




--
Utilisez notre serveur de news 'news.foorum.com' depuis n'importe ou.
Plus d'info sur : http://nnrpinfo.go.foorum.fr/


Avatar
Roumegou
100 fois débattus ce sujet, je vous invite à regarder dans les archives
de ce forum où vous trouverez les arguments de chacun.

Florian B. vient de nous annoncer :


Pour rappel Hyper File est un SGBDR complet... tu dois vouloir basculer vers
du client/serveur et plus du séquentiel indexé... Dans ce cas pourquoi ne
pas attendre la version client/serveur de Hyper File ? PC SOFT aura
certainement fait en sortie que les traitements restent les mêmes, même si
l'utilisation de requêtes est toujours à privilégier en client/serveur par
rapport à des lectures enreg par enreg (Hyper File est inbatable là dessus).



juste une remarque: pourquoi attendre une sortie (et peut-on attendre
? et jusqu'à quand ?) d'une nouvelle version HF qui ne résoudra pas le
problème number One, rédhibitoire et insolluble d'Hyperfile : C'est un
sgbd propriétaire et fermé à l'utilisation d'autres outils.
A chacun son métier et PCSoft qui a avec WD un super environnement de
dev n'est pas et ne sera jamais un acteur dans les SGBD.


A+




--
Eric Roumégou
http://cerbermail.com/?TSoulBerPA
(cliquez sur le lien ci-dessus pour me contacter en privé)
Avatar
Manu
Florian B. wrote:
Pour rappel Hyper File est un SGBDR complet... tu dois vouloir
basculer vers du client/serveur et plus du séquentiel indexé... Dans
ce cas pourquoi ne pas attendre la version client/serveur de Hyper
File ? PC SOFT aura certainement fait en sortie que les traitements
restent les mêmes, même si l'utilisation de requêtes est toujours à
privilégier en client/serveur par rapport à des lectures enreg par
enreg (Hyper File est inbatable là dessus).



Oui mais c'est prévu pour quand ??

car souvent les clients veulent une réponse peu couteuse et très rapide à
leur besoin.

--
Emmanuel
Avatar
Manu
> Bonjour,
Le projet sur lequel je travaille a été migré de WD5.5 et WD8 et est
devenu inexploitable à cause des lenteurs HF7 (jusqu'à 20 fois + lent
que WD5.5/HF5).



Cà c'est pas normal !

tu utilises le même mode de lecture ?
tu as tenté les requetes avec des HOptimiseRequete ?

Tu as un exemple ?

Les utilisateurs (le logiciel est en exploitation)
ne pourront pas attendre une "hypothétique" sortie de
HF-client/serveur. Nous sommes donc en train d'étudier le basculement
vers un autre système de fichiers, plus performant (MySQL ou autres)


Avatar
I.G.LOG
J'ai tout essayé: modification du mode de lecture vues->sql (et vice-versa
car l'accès est plus ou moins rapide selon les cas sans que je puisse
définir une règle), HOptimiseRequete, etc, etc...
Le problème est référencé chez PC-Soft (incident 39492) mais quand va-t-il
être résolu ?

"Manu" a écrit dans le message de
news:caouu4$mrd$
> Bonjour,
> Le projet sur lequel je travaille a été migré de WD5.5 et WD8 et est
> devenu inexploitable à cause des lenteurs HF7 (jusqu'à 20 fois + lent
> que WD5.5/HF5).

Cà c'est pas normal !

tu utilises le même mode de lecture ?
tu as tenté les requetes avec des HOptimiseRequete ?

Tu as un exemple ?

> Les utilisateurs (le logiciel est en exploitation)
> ne pourront pas attendre une "hypothétique" sortie de
> HF-client/serveur. Nous sommes donc en train d'étudier le basculement
> vers un autre système de fichiers, plus performant (MySQL ou autres)






Avatar
mat
I.G.LOG wrote:
Bonjour,
Le projet sur lequel je travaille a été migré de WD5.5 et WD8 et est devenu
inexploitable à cause des lenteurs HF7 (jusqu'à 20 fois + lent que
WD5.5/HF5). Les utilisateurs (le logiciel est en exploitation) ne pourront



Ce n'est certes pas normal. Si l'application a fonctionné sous WD 5.5,
je crois on y arrive maintenant aussi avec 7.5 et pour autant que je
sache, les requ'etes en WD8 sont fondamentalement inchangés à 7.5.
Je pense vous devriez sérieusement revoir votre code SQL qui diffère
probablement beaucoup dans les 2 versions. Pour donner un exemple, voici
un extrait de ton post du 7 mai:

Quote...
Pour résumer:
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.

Une autre technique qui améliore beaucoup la vitesse sous HF7 sont les
sous-requêtes avec "IN" et cet exemple en est un candidat parfait. Voir
mon post du 10 juin "Re: Performances décevantes de HF7" et autres à ce
sujet.

Autre point du même post:
Quote....
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 fonctionne pas ! (pb de jointures externes "chainees")
Unquote....

Je ne comprends pas "jointures externes chainées", mais quelque part tu
avais aussi dit qu'on ne pouvait pas inclure un même fichier deux fois.
J'ai récemment écrit le code suivant qui fonctionne de manière
incroyablement rapide pour HF:

"FROM Invoice INNER JOIN InvoiceDetail ON Invoice.IDInvoice InvoiceDetail.IDInvoice, "+...
"Address as Supp RIGHT OUTER JOIN Invoice ON Invoice.IDCustSupp Supp.IDAddress, "+...
"Address as Wareh RIGHT OUTER JOIN InvoiceDetail ON
InvoiceDetail.IDWarehouse = Wareh.IDAddress, "+...
"Product RIGHT OUTER JOIN InvoiceDetail ON InvoiceDetail.IDProduct Product.IDProduct, "+...
"ProductGroup RIGHT OUTER JOIN Product ON Product.IDProductGroup ProductGroup.IDProductGroup, "+...
"ProductRange RIGHT OUTER JOIN ProductGroup ON
ProductRange.IDProductRange = ProductGroup.IDProductRange, "+...
"BusinessSector RIGHT OUTER JOIN ProductRange ON
BusinessSector.IDBusinessSector = ProductRange.IDBusinessSector "+...
" WHERE InvoiceDetail.Balance <>0 AND InvoiceDetail.RecType >= 10 AND
InvoiceDetail.RecType <= 19 "
//----------------------------------------//
// Filter on Address Group
//----------------------------------------//
SI PAS pgf.cboFltAddressGroup..ValeurAffichée ="" ALORS
vQuery +=...
// Including InvoiceDetail / Invoice is imperative to make this filter work
"AND InvoiceDetail.IDInvoice IN (SELECT Invoice.IDInvoice FROM Invoice
"+...
"WHERE Invoice.IDCompany IN (SELECT Address_AddressGroup.IDAddress FROM
Address_AddressGroup "+...
"WHERE Address_AddressGroup.IDAddressGroup="+pgf.cboFltAddressGroup+")) "
FIN

... il y en a encore un paquet de filtres conditionels. Et cela n'est
que la moitié de la requête. L'autre moitie, utilisant partiellement
d'autres fichers se trouve dans une requête UNION et inclue le même
nombre de filtres.

Tout cela pour dire que, OUI, HF7 est loin d'etre satisfaisant pour le
développeur, mais en étudiant de près la syntaxe des requêtes on arrive
à obtenir des résultats satisfaisant probablement pour la plupart des gens.
Avatar
I.G.LOG
> Ce n'est certes pas normal. Si l'application a fonctionné sous WD 5.5,
je crois on y arrive maintenant aussi avec 7.5 et pour autant que je
sache, les requ'etes en WD8 sont fondamentalement inchangés à 7.5.
Je pense vous devriez sérieusement revoir votre code SQL qui diffère
probablement beaucoup dans les 2 versions.



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.

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 !?

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 fonctionne pas ! (pb de jointures externes "chainees")

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)

"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
Avatar
Manu
Bonjour mat,

Le projet sur lequel je travaille a été migré de WD5.5 et WD8 et est
devenu inexploitable à cause des lenteurs HF7 (jusqu'à 20 fois +
lent que WD5.5/HF5). Les utilisateurs (le logiciel est en
exploitation) ne pourront



Ce n'est certes pas normal. Si l'application a fonctionné sous WD 5.5,



Même constatation

je crois on y arrive maintenant aussi avec 7.5 et pour autant que je
sache, les requ'etes en WD8 sont fondamentalement inchangés à 7.5.
Je pense vous devriez sérieusement revoir votre code SQL qui diffère
probablement beaucoup dans les 2 versions. Pour donner un exemple,
voici un extrait de ton post du 7 mai:



[CUT]
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.



On croirais entendre Eric R la dessus lol

Une autre technique qui améliore beaucoup la vitesse sous HF7 sont les
sous-requêtes avec "IN" et cet exemple en est un candidat parfait.
Voir mon post du 10 juin "Re: Performances décevantes de HF7" et
autres à ce sujet.



C'est vrai que chaque sgbd a ses petites préférences en terme de requetage.

Autre point du même post:
Quote....
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 fonctionne pas ! (pb de jointures externes "chainees")
Unquote....

Je ne comprends pas "jointures externes chainées", mais quelque part
tu avais aussi dit qu'on ne pouvait pas inclure un même fichier deux
fois. J'ai récemment écrit le code suivant qui fonctionne de manière
incroyablement rapide pour HF:



Tu pourras remarquer que dans ton exemple ce sont de RIGHT OUTER et que dans
son exemple ce sont des LEFT OUTER join. Cela explique peut-être...

... il y en a encore un paquet de filtres conditionels. Et cela n'est
que la moitié de la requête. L'autre moitie, utilisant partiellement
d'autres fichers se trouve dans une requête UNION et inclue le même
nombre de filtres.



Désolé mais quand je vois ta requete je comprends maintenant les personnes
qui pensent qu'avec une requete on peut tout résoudre :-(

Tout cela pour dire que, OUI, HF7 est loin d'etre satisfaisant pour le
développeur, mais en étudiant de près la syntaxe des requêtes on
arrive à obtenir des résultats satisfaisant probablement pour la plupart


des
gens.



çà c'est vrai et c'est ce qui me fait penser qu'il y a un loup dans le pb
initial.

--
Emmanuel
Avatar
I.G.LOG
Bonjour Manu,
Le projet a ete migre de WD5.5 a WD8 sans qu'il y ait eu de changement dans
les methodes d'acces !!! (vues et fonctions H*, pas de SQL). Les lenteurs
ont ete constatees par PCS et l'incident est enregistre par leur service
technique
Pour le reste, suis en train d'etudier le code de Mat (pour ma culture SQL)

"Manu" a écrit dans le message de
news:capigu$s6h$
Bonjour mat,

>> Le projet sur lequel je travaille a été migré de WD5.5 et WD8 et est
>> devenu inexploitable à cause des lenteurs HF7 (jusqu'à 20 fois +
>> lent que WD5.5/HF5). Les utilisateurs (le logiciel est en
>> exploitation) ne pourront
>
> Ce n'est certes pas normal. Si l'application a fonctionné sous WD 5.5,

Même constatation

> je crois on y arrive maintenant aussi avec 7.5 et pour autant que je
> sache, les requ'etes en WD8 sont fondamentalement inchangés à 7.5.
> Je pense vous devriez sérieusement revoir votre code SQL qui diffère
> probablement beaucoup dans les 2 versions. Pour donner un exemple,
> voici un extrait de ton post du 7 mai:

> [CUT]
> 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.

On croirais entendre Eric R la dessus lol

> Une autre technique qui améliore beaucoup la vitesse sous HF7 sont les
> sous-requêtes avec "IN" et cet exemple en est un candidat parfait.
> Voir mon post du 10 juin "Re: Performances décevantes de HF7" et
> autres à ce sujet.

C'est vrai que chaque sgbd a ses petites préférences en terme de


requetage.

> Autre point du même post:
> Quote....
> 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 fonctionne pas ! (pb de jointures externes "chainees")
> Unquote....
>
> Je ne comprends pas "jointures externes chainées", mais quelque part
> tu avais aussi dit qu'on ne pouvait pas inclure un même fichier deux
> fois. J'ai récemment écrit le code suivant qui fonctionne de manière
> incroyablement rapide pour HF:

Tu pourras remarquer que dans ton exemple ce sont de RIGHT OUTER et que


dans
son exemple ce sont des LEFT OUTER join. Cela explique peut-être...

> ... il y en a encore un paquet de filtres conditionels. Et cela n'est
> que la moitié de la requête. L'autre moitie, utilisant partiellement
> d'autres fichers se trouve dans une requête UNION et inclue le même
> nombre de filtres.

Désolé mais quand je vois ta requete je comprends maintenant les personnes
qui pensent qu'avec une requete on peut tout résoudre :-(

> Tout cela pour dire que, OUI, HF7 est loin d'etre satisfaisant pour le
> développeur, mais en étudiant de près la syntaxe des requêtes on
> arrive à obtenir des résultats satisfaisant probablement pour la plupart
des
> gens.

çà c'est vrai et c'est ce qui me fait penser qu'il y a un loup dans le pb
initial.

--
Emmanuel




1 2 3