OVH Cloud OVH Cloud

[WD9] Hyper File CS

39 réponses
Avatar
Frédéric LAMBOUR
Y a un truc qui m'inquiète. Quand on importe une base HF classic dans HF
client serveur à aucun moment le serveur ne demande l'analyse HF
correspondant à la base de donnée. Comment le serveur fait-il donc pour
assurer l'intégrité de la base de donnée sans l'analyse ?

Je fais faire quelque test ...

9 réponses

1 2 3 4
Avatar
sebNews
"ANTOINE" a écrit dans le message de
news:4361441b$0$16487$
Effectivement une base client serveur de moins d'un an doit mûrir. Ils ne
peuvent pas proposer en si peu de temps toutes les fonctionnalités


d'autres
bases qui plus de 10 ans de vécu. Ce qui est vraiment bien toutefois,


c'est
que le passage d'une base (HF) à l'autre (HF CS) est actuellement ultra
simple. Donc, malgré un certain manque de fonctionnalités, je suis plutôt
optimiste. Nous auront certainement de bonnes surprises dans les mois
prochains.



On se contentera de lui demander de remplir les fonctionnalités annoncées.

Le problème ne vient pas du manque de fonctionnalités ou du manque de
maturité,
mais simplement des effets d'annonce qui n'ont plus lieu d'être.



Sébastien
Avatar
Daniel
Salut,
"ANTOINE" writes:

Effectivement une base client serveur de moins d'un an doit mûrir.



Je suis d'accord.


ne peuvent pas proposer en si peu de temps toutes les fonctionnalités
d'autres bases qui plus de 10 ans de vécu.


Tu peux même parler de 20 ans. Mais dans ce cas quel est l'intéret de
proposer une nouvelle base qui a 10 ans de retard sur ce qui existe
sur le marché :-(

Ce qui est vraiment bien
toutefois, c'est que le passage d'une base (HF) à l'autre (HF CS) est
actuellement ultra simple.



Ce n'est pas trop ce qui est dit.

Donc, malgré un certain manque de
fonctionnalités, je suis plutôt optimiste. Nous auront certainement de
bonnes surprises dans les mois prochains.

Antoine




Sérieusement, tu penses ce que tu écris ?
Il serait plus simple et plus "professionnel" de dire que HF C/S est
en version beta actuellement et que le déploiement en production ne
doit pas être fait, ou si il est fait c'est aux risques et périls de
celui qui le fait :-((




--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
Avatar
Daniel
"ANTOINE" writes:

"Eric Demeester" <eric+ a écrit dans le message de news:

> dans (in) fr.comp.developpement.agl.windev, "ANTOINE"
> ecrivait (wrote) :
>
> Bonsoir,
>
>> Effectivement une base client serveur de moins d'un an doit mûrir. I ls ne
>> peuvent pas proposer en si peu de temps toutes les fonctionnalités
>> d'autres
>> bases qui plus de 10 ans de vécu.
>
> Si tu regardes les publicités pour Windev 2 (peut-être même Winde v 1),
> tu t'apercevras que Pc-Soft présentait déjà à l'époque HF com me
> client/serveur alors qu'il n'en était rien. Alors les 10 ans de véc u,
> ils auraient pu les utiliser à faire un vrai sgbd client/serveur plut ôt
> que de faire croire que c'en était un alors que ce n'était pas le c as,
> tu ne penses pas ?
>
>> Ce qui est vraiment bien toutefois, c'est
>> que le passage d'une base (HF) à l'autre (HF CS) est actuellement ul tra
>> simple.
>
> Peut-être, mais si on n'adapte pas le code pour optimiser les requê tes à
> la base, qu'elle devienne CS ne change _rien_ aux performances, c'est
> particulièrement flagrant en accès distant. Comme le principal int éret
> de passer en CS réside dans la rapidité d'accès à la base en ac cès
> distant, euh, comment dire ?

Ok mais comme avec toute autre base de données client serveur.
Si tu ne fait pas de requêtes en SQL Server ou que tes requêtes ne so nt pas
adaptées, par exemple quelles remontent beaucoup trop de rubriques en
mémoire, voir des mémos, et que c'est inutile, tu auras exactement le même
problème. Le passage en HF CS nécessite bien évidement quelques
modifications de ton code mais tout bon développeur ce doute de cela.
Cependant, ce qu'ils annoncent au départ est vrai, en deux lignes de co de tu
passes d'une base à l'autre.

Antoine



Devons nous comprendre qu'il est préférable de programmer en SQL au
lieu des ordres H?

Le problème, je pense est à autre niveau, si effectivement pour
optimiser les échanges entre la base et le client il faut être en SQL
qu'on le dise clairement dans le manuel en écrivant que les ordres H
ne sont pas optimisés.

Perso celà ne me gène pas car je trouve que Windev est un bon outil si
on utilise le SQL sur des SGBDR éprouvés.

Toutefois, le plus gros problème est pour les sociétés qui ont des
grosses applis qui repose sur HF et ordre H et que ils n'ont pas
vraiment le choix et ils sont obligés de subir cette situation.


>
> De mon point de vue, si on gère un existant, optimiser le code pour
> passer en HF CS prend autant de temps que de le changer pour passer à
> des sgbd non propriétaires, et il n'y a pas photo, quitte à passer ce
> temps, autant migrer vers une base de données non propriétaire.
>
>> Donc, malgré un certain manque de fonctionnalités, je suis plutôt
>> optimiste. Nous auront certainement de bonnes surprises dans les mois
>> prochains.
>
> Demain on rase gratis :)
>
> --
> Eric





--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
Avatar
ANTOINE
"Daniel" a écrit dans le message de news:

"ANTOINE" writes:

"Eric Demeester" <eric+ a écrit dans le message de
news:

> dans (in) fr.comp.developpement.agl.windev, "ANTOINE"
> ecrivait (wrote) :
>
> Bonsoir,
>
>> Effectivement une base client serveur de moins d'un an doit mûrir. Ils
>> ne
>> peuvent pas proposer en si peu de temps toutes les fonctionnalités
>> d'autres
>> bases qui plus de 10 ans de vécu.
>
> Si tu regardes les publicités pour Windev 2 (peut-être même Windev 1),
> tu t'apercevras que Pc-Soft présentait déjà à l'époque HF comme
> client/serveur alors qu'il n'en était rien. Alors les 10 ans de vécu,
> ils auraient pu les utiliser à faire un vrai sgbd client/serveur plutôt
> que de faire croire que c'en était un alors que ce n'était pas le cas,
> tu ne penses pas ?
>
>> Ce qui est vraiment bien toutefois, c'est
>> que le passage d'une base (HF) à l'autre (HF CS) est actuellement ultra
>> simple.
>
> Peut-être, mais si on n'adapte pas le code pour optimiser les requêtes à
> la base, qu'elle devienne CS ne change _rien_ aux performances, c'est
> particulièrement flagrant en accès distant. Comme le principal intéret
> de passer en CS réside dans la rapidité d'accès à la base en accès
> distant, euh, comment dire ?

Ok mais comme avec toute autre base de données client serveur.
Si tu ne fait pas de requêtes en SQL Server ou que tes requêtes ne sont
pas
adaptées, par exemple quelles remontent beaucoup trop de rubriques en
mémoire, voir des mémos, et que c'est inutile, tu auras exactement le même
problème. Le passage en HF CS nécessite bien évidement quelques
modifications de ton code mais tout bon développeur ce doute de cela.
Cependant, ce qu'ils annoncent au départ est vrai, en deux lignes de code
tu
passes d'une base à l'autre.

Antoine



Devons nous comprendre qu'il est préférable de programmer en SQL au
lieu des ordres H?

Perso celà ne me gène pas car je trouve que Windev est un bon outil si
on utilise le SQL sur des SGBDR éprouvés.

Le problème, je pense est à autre niveau, si effectivement pour
optimiser les échanges entre la base et le client il faut être en SQL
qu'on le dise clairement dans le manuel en écrivant que les ordres H
ne sont pas optimisés.

Toutefois, le plus gros problème est pour les sociétés qui ont des
grosses applis qui repose sur HF et ordre H et que ils n'ont pas
vraiment le choix et ils sont obligés de subir cette situation.

Non, ce n'est pas du tout ce que je dis, bien au contriare.
Je dis qu'il faut :
- éviter de travailler directement sur les fichier en utilisant des requetes
- les requete sont exécutée avec les ordres H bien entendu
(HExecuteRequete())

Dans son contexte, on peut passer d'une application HF à HF CS relativement
rapidement puique la quasi totalité du code restera la meme.

Antoine

>
> De mon point de vue, si on gère un existant, optimiser le code pour
> passer en HF CS prend autant de temps que de le changer pour passer à
> des sgbd non propriétaires, et il n'y a pas photo, quitte à passer ce
> temps, autant migrer vers une base de données non propriétaire.
>
>> Donc, malgré un certain manque de fonctionnalités, je suis plutôt
>> optimiste. Nous auront certainement de bonnes surprises dans les mois
>> prochains.
>
> Demain on rase gratis :)
>
> --
> Eric





--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
Avatar
ANTOINE
"Daniel" a écrit dans le message de news:


Salut,
"ANTOINE" writes:

Effectivement une base client serveur de moins d'un an doit mûrir.



Je suis d'accord.


ne peuvent pas proposer en si peu de temps toutes les fonctionnalités
d'autres bases qui plus de 10 ans de vécu.


Tu peux même parler de 20 ans. Mais dans ce cas quel est l'intéret de
proposer une nouvelle base qui a 10 ans de retard sur ce qui existe
sur le marché :-(

Ce qui est vraiment bien
toutefois, c'est que le passage d'une base (HF) à l'autre (HF CS) est
actuellement ultra simple.



Ce n'est pas trop ce qui est dit.

Pourquoi ?
Le passage de l'un à l'autre, c'est deux lignes de code. HOuvreconnexion et
HChangeconnexion.
Aves cela, ton appli travail réellement en CS, c'est ce qui a été annocé et
c'est kla vérité.
Il est vrai qu'après il est préférable (mais pas obligatoire pour que cela
fonctionne) surtout pour de l'ADSL de faire des modifs afin d'optimiser les
traitements (comme indiqué dans mes précédents messages sur ce post).

Donc, malgré un certain manque de
fonctionnalités, je suis plutôt optimiste. Nous auront certainement de
bonnes surprises dans les mois prochains.

Antoine




Sérieusement, tu penses ce que tu écris ?
Il serait plus simple et plus "professionnel" de dire que HF C/S est
en version beta actuellement et que le déploiement en production ne
doit pas être fait, ou si il est fait c'est aux risques et périls de
celui qui le fait :-((

Bien sur que je le pense, pcsoft nous fourni régulièrement des nouveautés.
Bientot les transactions ne seront plus en beta et j'espere que l'on aura la
possibilté par exemple d'utiliser des procédures stockées...

Antoine




--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
Avatar
mat
ANTOINE wrote:
Tu peux donc passer directement à la 10 qui propose maintenant cette
fonctionnalité.




j'ai un nouvel exemple pour expliquer pourquoi je ne peux pas me
permettre cela. J'ai fait les premiers tests en WD9 et, effectivement ça
ne plante pas à la première ouverture comme avec WD8. En testant les
fenêtres les plus importantes, je ne vois aucune différence de rapidité,
mais il faudra vérifier aussi en réseau ce que je n'ai pas encore fait.

Bien évidemment je rencontre des problèmes dès qu'une requête commence à
être un peu plus complexe de la norme (archisimple pour des raisons de
performance). L'exemple est intéressant, car j'utilise le même nom de
requête (présent aussi sous un des formats dans le projet). Sauf s'il y
a eu un changement non documenté, hExecuteRequeteSQL permet d'utiliser
le nom d'une requête enregistrée et la modifier à volonté. Alors, j'ai
un set de données identiques à la sortie qui peuvent venir de sources
différentes. Puisque nous faisons fortement usage de classes et
procédures globales/partagées, alors tout le traitement, sauf la
composition de la requête elle-même est identique. Le résultat de la
première requête s'affiche dans la table, tandis que la 2e fait geler
l'écran. HExecuteRequeteSQL est suivi par une boucle "POUR TOUS
maRequete sur..." et c'est au moment de la lecture du résultat que ça
bloque (un debug s'arrête à la ligne POUR TOUS mais ne bouge pas à la 1è
ligne de la boucle).

En cherchant la cause, j'ai remarqué une différence avec WD8, bien sûr
sans documentation: sous WD8 lorsqu'on fait hNbEnr(maRequête), Windev
attend la fin de lecture de la requête. Je sais qu'à partir de là le
résultat est présent. Ce n'est plus le cas, car une simple commande
Info(HNbEnr(qSQL)) envoie WD9 au Nirvana. Un multitask(100) résout le
problème, mais l'exigence de retard est bien sûr variable avec le nombre
de lignes dans le résultat ou suivant la complexité. Il me semble que
PCSoft ont essayé d'accélérer le retour du thread d'exécution de la
requête et sont allés trop loin pour certains types de requêtes,
c'est-à-dire le programme ne réussit pas de lire le fichier résultat,
p.ex. avec HNrEnr ou dans une boucle POUR TOUS maRequete. Ceci sûrement
afin d'obtenir une "exécution" plus rapide, en cachant encore plus
qu'elle continue à s'exécuter en arrière plan. Mais sur la 2e requête,
même une attente de 30 secondes (temps d'exécution normal sous WD8 = 23
secondes) ne sert à rien.

Ce n'est probablement pas facile de comprendre les deux requêtes,
surtout la 2e. Mais les deux fonctionnent sans problème sous WD8, la
première est rapide (puisque "optimisée" à n'utiliser qu'un fichier et
chercher le reste dans une boucle POUR TOUS, la 2e est lente à cause du
group by, mais cela ne gêne pas trop. J'utilise ensuite bien sûr la même
boucle POUR TOUS pour obtenir les descriptions des différents fichiers.

Sous condition que je trouve la motivation, je vais probablement finir
par trouver de contournements, mais après combien d'heures de travail?
Après tous ce que j'ai déjà dû faire pour obtenir juste des résultats
semblables au standard d'autre produits, être confronté à de telles
régressions est particulièrement frustrant. Et je crains que tu ne vas
pouvoir m'aider au dela des recommendations de passer directement à
la version 10 ;-). Donc, pour l'instant aucune raison de changer mon
opinion sur HF. C'est à éviter lorsqu'on parle requête.

Salutations
Mat


1) La requête suivante passe:
============================ SELECT …
FROM InvoiceDetail WHERE InvoiceDetail.Balance <>0 AND
InvoiceDetail.RecType >= 10 AND InvoiceDetail.RecType <= 19 AND
(InvoiceDetail.IsActive = 1 or InvoiceDetail.RecType = 19) AND
InvoiceDetail.IDCompany = 2

UNION

SELECT …
FROM ContractDetail
WHERE ContractDetail.Balance <> 0
AND ContractDetail.IsActive = 1
AND ContractDetail.IDContract IN (SELECT Contract.IDContract FROM
Contract WHERE IDCompany = 2)
ORDER BY BusinessSector,ProductRange,ProductGroup,IDProduct,ContType,
Date, ItemKey

2) Celle-ci ne passe pas:
======================== Select …
FROM Transaction
WHERE Transaction.IDRecType = 0
AND Transaction.IsNew = 0
AND Transaction.Date <= '20051028'
AND Transaction.IDInvoice + (Transaction.InvoiceItem/1000) IN (SELECT
IDInvoice + (InvoiceItem/1000) FROM Transaction as T WHERE T.IdInvoice
= Transaction.IDInvoice AND T.InvoiceItem = Transaction.InvoiceItem AND
T.IDCompany = Transaction.IDcompany AND T.IDWarehouse Transaction.IDWarehouse AND IDRecType = 0 AND IsNew = 0 AND Date < '20051028' GROUP BY IDInvoice + (InvoiceItem/1000), IDcompany,
IDWarehouse Having sum(T.Quantity)<>0) AND Transaction.IDCompany = 2

UNION

SELECT…
FROM Transaction
WHERE (Transaction.IDRecType = 1 or Transaction.IDRecType =2)
AND Transaction.IsNew = 0
AND Transaction.Date <= '20051028'
AND Transaction.IDcontract + (Transaction.ItemNo/1000) IN (SELECT
IDContract + (ItemNo/1000) FROM Transaction as T WHERE T.IDContract Transaction.IDContract AND T.ItemNo = Transaction.ItemNo AND T.IdCompany
= Transaction.IDcompany AND (IDRecType = 1 OR IDRecType = 2) AND IsNew
= 0 AND Date <= '20051028' GROUP BY T.IDContract + (T.ItemNo/1000)
Having sum(T.Quantity)<>0) AND Transaction.IDCompany = 2
ORDER BY BusinessSector, ProductRange, ProductGroup, IDProduct,
ContType, IDCompany, ItemKey, Warehouse_Ref, Date, LineNo


3) Cette requête n'est pas lié aux deux ci-haut, marche parfaitement
sous WD8 et seulement aléatoirement sous WD9.
Elle est exécuté dans une classe, le programme devrait retourner ensuite
à la fenêtre. Où est le responsable? La requête (assez simple) ou le
fait qu'elle est exécuté dans une classe et que HF a de la peine à
retourner le contrôle à Windev? Pas facile d'établir la cause. Bien
évidemment il y a aussi une boucle POUR TOUS maRequete sur...
======================================================================= FROM InvoiceDetail
INNER JOIN Invoice ON InvoiceDetail.IDInvoice = Invoice.IDInvoice
WHERE Invoice.IsNew = 0
AND Invoice.RecType >= 20
AND Invoice.RecType <= 29
AND Invoice.IDInvoice IN (SELECT InvoiceDetail.IDInvoice FROM
InvoiceDetail WHERE InvoiceDetail.IDCompany IN (SELECT AG.IDAddress
FROM Address_AddressGroup AS AG WHERE AG.IDAddressGroup=1))
ORDER BY BusinessSector, ProductRange, ProductGroup, IdProduct, Date
Avatar
sebNews
>
Bien sur que je le pense, pcsoft nous fourni régulièrement des nouveautés.
Bientot les transactions ne seront plus en beta et j'espere que l'on aura


la
possibilté par exemple d'utiliser des procédures stockées...

Antoine




Sinon il fait beau sur la côte ?
Avatar
Eric Demeester
dans (in) fr.comp.developpement.agl.windev, "ANTOINE"
ecrivait (wrote) :

Bonsoir,

Tu peux même parler de 20 ans. Mais dans ce cas quel est l'intéret de
proposer une nouvelle base qui a 10 ans de retard sur ce qui existe
sur le marché :-(



C'est pile-poil ce que fait Pc-Soft avec HF client/serveur, pourtant.

Il serait plus simple et plus "professionnel" de dire que HF C/S est
en version beta actuellement et que le déploiement en production ne
doit pas être fait, ou si il est fait c'est aux risques et périls de
celui qui le fait :-((



Voila. Des exemples _crédibles_ disponibles publiquement attestant que
HF/CS fonctionne sous Windows comme sous Unix seraient également les
bienvenus.

Bien sur que je le pense, pcsoft nous fourni régulièrement des nouveautés.



Corriger les bugs des versions antérieures avant de proposer des
nouveautés serait un progrès apprécié par la communauté des clients de
Pc-SOft, vous pouvez en informer la direction de ma part.

--
Eric
Avatar
Emmanuel Lecoester
> > Il serait plus simple et plus "professionnel" de dire que HF C/S est
> en version beta actuellement et que le déploiement en production ne
> doit pas être fait, ou si il est fait c'est aux risques et périls de
> celui qui le fait :-((

Voila. Des exemples _crédibles_ disponibles publiquement attestant que
HF/CS fonctionne sous Windows comme sous Unix seraient également les
bienvenus.



J'ai un prospect qui utilise HF C/S en *production* sur une dizaine de sites
avec 2 PC dont l'un sert de Serveur. Il ne m'a pas remonté d'informations
négatives.

Si on signe, on achète WD9 donc je pourrai faire des tests plus poussés.
1 2 3 4