[WD 7.5] Grosses difficultés avec la réplication

Arnaud DESMAZES avait soumis l'idée :

Bonjour,

comme le sujet est assez évocateur, j'en viens au faits de suite.

je développe une application de gestion commerciale pour l'un de mes
clients. Le gros problème est qu'il vient d'ouvrir une agence à 500 km
du siège. Voici la configuration :

----------- ----------

SIEGE | <------ LS 256 K (VPN) -------> | AGENCE |
SRV_SIEGE| | SRV_AG |

----------- ----------
* 15 PC * 2 PC
* 4 PORTABLES * 2 PORTABLES

Entre temps, l'idée de pouvoir embarquer une copie de la base sur les
portables est apparue. Je me suis dit :" Heureusement, la réplication
est là ! " Bien mal m'en a pris puisque j'essaie, en vain, de trouver
la réplication dans l'exemple WD7 Replication de la LST 52.. Là n'est
pas le débat, revenons à mon problème.

La connexion en temps réel entre l'agence et le siège sur
l'application est impossible car le temps d'accès à la fenetre
d'identification de la base approche les 5mn !
La base compte 30 fichiers HF. L'agence et les machines qui lui sont
rattachées n'ont le droit de modifier/supprimer des enregistrements
que sur 6 fichiers de la base, par contre ils peuvent consulter
l'ensemble des 24 autres.

Scénario :
L'ensembles des 17 PC et des 6 Portables saisissent des informations
au quotidien. Les portables ont le choix d'etre en mode "connecté" ou
"autonome" ainsi ils récupèrent l'etat le plus récent de la base de
données sur le serveur qui leur est dédié.
Chaque nuit, les serveurs SRV_SIEGE et SRV_AG se synchronisent afin de
mettre à jour les informations saisies par l'ensembles des postes. La
journée le serveur de l'agence a une copie de la base de données de la
veille. Les postes clients de l'agence travaillent sur cette copie.
Les portables doivent pouvoir mettre à jour le serveur à tout moment
(ou peut etre celà va t il générer des blocages dans les fichiers ?)

Avez vous une idée de la marche à suivre afin de mettre ce scénario en
place ?
Dans l'analyse, dois je gérer la réplication pour 6 ou 30 fichiers ?
L'outil WDReplic peut il m'aider ou dois je gérer complétement la
replication "à la main" ? Les identifiants des 6 fichiers sont pour
l'instant sur 8 octets et sont déclarés en tant qu'identifiants
automatiques.

Je ne sais pas si je suis très clair dans mes propos mais j'ai
vraiment besoin d'une solution étant donné que c'est pour un
client....J'hésite, cependant, à me tourner vers la hotline gratuite
pour ce problème "pas assez précis".

Merci d'avance pour votre aide.

Cordialement,

Arnaud DESMAZES

Salut,

As tu regardé dans la lst 54 ou 55. il y a un exemple de réplication
sympa.

A+
Adrien.

--
Ceci est une signature automatique de MesNews.
Site : http://mesnews.no-ip.com

Bonjour

Je trouve que la réplication dans ce cas de figure est de la *vieille*
informatique
Il faut faire du temps réel
Si les temps de réponse sont mauvais, c'est qu'il faut adapter l'application
pour l'accès à distance.
Avec abonnement ADSL tu dois pouvoir partager les données.
Et ça vaut certainement le coup de passer en 8 pour bénéficier du profiler et
analyser ce qui prend vraiment du temps dans l'appli pour l'adapter (exemple
typique: modifier une boucle de HLitRecherche par une requête). Et en plus
certaines requêtes sont plus rapides en 8 qu'en 7.5.
Mais bon, en 2004, des agences doivent utiliser les mêmes données en temps réel
!

P.



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

dans (in) fr.comp.developpement.agl.windev, Prive <prive@prive.nospam>
ecrivait (wrote) :

Bonjour,

Je trouve que la réplication dans ce cas de figure est de la *vieille*
informatique

Oui, mais...

Il faut faire du temps réel

Ca fait un an que j'essaye :)

Si les temps de réponse sont mauvais, c'est qu'il faut adapter l'application
pour l'accès à distance.
Avec abonnement ADSL tu dois pouvoir partager les données.

Mon expérience :

- base de données HF hébergée dans un datacenter sur un serveur
Samba/FreeBSD disposant de 2 Mbps symétriques.

- clients derrière de l'ADSL 1024/128 France-Telecom accédant à la base
de données par VPN.

Donc a priori côté infrastructure et connectivité (il y a mieux que
Wanadoo et Oléane mais le client ne veut pas changer), c'est plutôt au
dessus de la moyenne.

On a nettoyé le code tant qu'on pouvait, accéléré les échanges, ça fait
un an qu'on essaye, qu'on teste, qu'on peaufine, ça reste totalement et
irrémédiablement inutilisable, et le problème est identifié.

Le problème c'est Hyperfile, qui n'a de client/serveur que le nom, et
qui génère des mégas et des mégas de broadcast pour rechercher et
afficher trois malheureux enregistrements. Quand on fait une insertion
nécessitant la mise à jour en cascade de plusieurs fichiers, on a le
temps d'aller boire un café.

Solutions envisagées :

- migrer en MySQL. Trop de travail, l'appli date de 1992, compte
plusieurs centaines de fenêtres et évolue depuis en permanence.

- utiliser Citrix. Parfait, mais il faut aligner 8000 euros HT et ça
demande un mois d'ingénieur pour le configurer et installer l'appli
dessus. Le client ne veut bien entendu pas payer.

- utiliser TSE. La mise de fond est moindre (2500 euros HT en comptant
le serveur et les licences), le client ne veut pas payer non plus.

Mais bon, en 2004, des agences doivent utiliser les mêmes données en temps réel
!

Résultat des courses, on va faire de la réplication automatique par mail
et on va tout programmer nous même, parce que la réplication de Windev
n'est pas utilisable non plus.

Je précise que j'apprécie Windev sur de nombreux points, hein. Ce serait
à refaire, je pense que je referais, par contre je n'utiliserais pas
Hyperfile mais un vrai SGBDR client/serveur ouvert et multiplateformes,
donc MySQL ou PostgreSQL.

Mais qu'on ne me parle plus d'Hyperfile en environnement réseau en
général, et pour de l'accès distant en particulier.

--
Eric

Très interressante cette expérience.
Si l'application avait été développée pour un SGBD sql, et qu'au pire
le SGBD ne soit pas à la hauteur en matière de réplication, ou de C/S;
il n'aurait pas été trop dur de faire évoluer l'appli pour un autre
SGBD.
Et en misant sur des standards, c'est la pérénité assurée.
A la décharge de HF, l'appli date de 1992 et les solutions à l'époque
n'étaient pas pléthoriques.
Mais aujourd'hui, choisir Windev (pour moi c'est oui sans hésiter) mais
avec de l'HF (là ça me dépasse !)
Je comprends l'intérêt pour Pcsoft qui ainsi capte ses clients sur
leurs outils de développement et dérivés, mais côté client, là je ne
vois pas.

Eric Demeester a exprimé avec précision :

dans (in) fr.comp.developpement.agl.windev, Prive <prive@prive.nospam>
ecrivait (wrote) :

Bonjour,

Je trouve que la réplication dans ce cas de figure est de la *vieille*
informatique

Oui, mais...

Il faut faire du temps réel

Ca fait un an que j'essaye :)

Si les temps de réponse sont mauvais, c'est qu'il faut adapter l'application
pour l'accès à distance.
Avec abonnement ADSL tu dois pouvoir partager les données.

Mon expérience :

- base de données HF hébergée dans un datacenter sur un serveur
Samba/FreeBSD disposant de 2 Mbps symétriques.

- clients derrière de l'ADSL 1024/128 France-Telecom accédant à la base
de données par VPN.

Donc a priori côté infrastructure et connectivité (il y a mieux que
Wanadoo et Oléane mais le client ne veut pas changer), c'est plutôt au
dessus de la moyenne.

On a nettoyé le code tant qu'on pouvait, accéléré les échanges, ça fait
un an qu'on essaye, qu'on teste, qu'on peaufine, ça reste totalement et
irrémédiablement inutilisable, et le problème est identifié.

Le problème c'est Hyperfile, qui n'a de client/serveur que le nom, et
qui génère des mégas et des mégas de broadcast pour rechercher et
afficher trois malheureux enregistrements. Quand on fait une insertion
nécessitant la mise à jour en cascade de plusieurs fichiers, on a le
temps d'aller boire un café.

Solutions envisagées :

- migrer en MySQL. Trop de travail, l'appli date de 1992, compte
plusieurs centaines de fenêtres et évolue depuis en permanence.

- utiliser Citrix. Parfait, mais il faut aligner 8000 euros HT et ça
demande un mois d'ingénieur pour le configurer et installer l'appli
dessus. Le client ne veut bien entendu pas payer.

- utiliser TSE. La mise de fond est moindre (2500 euros HT en comptant
le serveur et les licences), le client ne veut pas payer non plus.

Mais bon, en 2004, des agences doivent utiliser les mêmes données en temps
réel !

Résultat des courses, on va faire de la réplication automatique par mail
et on va tout programmer nous même, parce que la réplication de Windev
n'est pas utilisable non plus.

Je précise que j'apprécie Windev sur de nombreux points, hein. Ce serait
à refaire, je pense que je referais, par contre je n'utiliserais pas
Hyperfile mais un vrai SGBDR client/serveur ouvert et multiplateformes,
donc MySQL ou PostgreSQL.

Mais qu'on ne me parle plus d'Hyperfile en environnement réseau en
général, et pour de l'accès distant en particulier.

--
Eric Roumégou
http://cerbermail.com/?TSoulBerPA
(cliquez sur le lien ci-dessus pour me contacter en privé)

dans (in) fr.comp.developpement.agl.windev, Roumegou
<Utilisezlelien@fin.msg> ecrivait (wrote) :

Bonsoir Eric,

Très interressante cette expérience.

Sauf pour mes pauvres nerfs :)

Si l'application avait été développée pour un SGBD sql, et qu'au pire
le SGBD ne soit pas à la hauteur en matière de réplication, ou de C/S;
il n'aurait pas été trop dur de faire évoluer l'appli pour un autre
SGBD.
Et en misant sur des standards, c'est la pérénité assurée.

C'est pile-poil mon raisonnement.

A la décharge de HF, l'appli date de 1992 et les solutions à l'époque
n'étaient pas pléthoriques.

Absolument. Je dirai même plus, les solutions alternatives à Windev/HF
étaient inexistantes en 1991 (1992 est la date de mise en prod du
portage Quick Basic de l'appli, qui existe depuis 1987), même VB et
Access n'existaient pas, et ayant senti la nécessité de migrer sous
Windows, j'ai naturellement choisi Windev 1.x.

A l'époque, c'était le seul AGL disponible sous Windows, j'ai été
fasciné par ses capacités en matière de développement d'IHM, et la base
de données intégrée, pour moi qui venait de QB et avait intégralement
développé les fonctions de gestion de ma base à partir de rien, c'était
magique (déclarer un index et ne pas être obligé de tout gérer à la
main, tu imagines le pieds que c'était ?).

Mais aujourd'hui, choisir Windev (pour moi c'est oui sans hésiter) mais
avec de l'HF (là ça me dépasse !)

Nous sommes d'accord à 100%.

Je comprends l'intérêt pour Pcsoft qui ainsi capte ses clients sur
leurs outils de développement et dérivés, mais côté client, là je ne
vois pas.

J'ai une seule vraie chose à reprocher à PcSoft, c'est cette volonté
qu'ils ont de pousser HF en avant tout en faisant tout pour que la base
de données reste un outil propriétaire inutilisable confortablement avec
autre chose que leurs outils de développement.

Je trouve ce comportement imbécile, parce que de nos jours, c'est
l'ouverture qui engendre le succès, pas le repli caractériel sur soi et
la paranoïa.

Mais bon, ça fait tellement longtemps que je tiens le même raisonnement
que je n'espère plus être entendu.

--
Eric

Eric Demeester wrote:

dans (in) fr.comp.developpement.agl.windev, Roumegou
<Utilisezlelien@fin.msg> ecrivait (wrote) :

Bonsoir Eric,

Très interressante cette expérience.

Sauf pour mes pauvres nerfs :)

Si l'application avait été développée pour un SGBD sql, et qu'au pire
le SGBD ne soit pas à la hauteur en matière de réplication, ou de
C/S; il n'aurait pas été trop dur de faire évoluer l'appli pour un
autre SGBD.
Et en misant sur des standards, c'est la pérénité assurée.

C'est pile-poil mon raisonnement.

A la décharge de HF, l'appli date de 1992 et les solutions à l'époque
n'étaient pas pléthoriques.

Absolument. Je dirai même plus, les solutions alternatives à Windev/HF
étaient inexistantes en 1991 (1992 est la date de mise en prod du
portage Quick Basic de l'appli, qui existe depuis 1987), même VB et
Access n'existaient pas, et ayant senti la nécessité de migrer sous
Windows, j'ai naturellement choisi Windev 1.x.

A l'époque, c'était le seul AGL disponible sous Windows, j'ai été
fasciné par ses capacités en matière de développement d'IHM, et la
base de données intégrée, pour moi qui venait de QB et avait
intégralement développé les fonctions de gestion de ma base à partir
de rien, c'était magique (déclarer un index et ne pas être obligé de
tout gérer à la main, tu imagines le pieds que c'était ?).

Mais aujourd'hui, choisir Windev (pour moi c'est oui sans hésiter)
mais avec de l'HF (là ça me dépasse !)

Nous sommes d'accord à 100%.

Je comprends l'intérêt pour Pcsoft qui ainsi capte ses clients sur
leurs outils de développement et dérivés, mais côté client, là je ne
vois pas.

J'ai une seule vraie chose à reprocher à PcSoft, c'est cette volonté
qu'ils ont de pousser HF en avant tout en faisant tout pour que la
base de données reste un outil propriétaire inutilisable
confortablement avec autre chose que leurs outils de développement.

Je trouve ce comportement imbécile, parce que de nos jours, c'est
l'ouverture qui engendre le succès, pas le repli caractériel sur soi
et la paranoïa.

Mais bon, ça fait tellement longtemps que je tiens le même
raisonnement que je n'espère plus être entendu.

Tout le monde dit la même chose d'AOL et pourtant, A ce jour AOL est bien
vivant....
Antoine

Antoine a présenté l'énoncé suivant :

Je trouve ce comportement imbécile, parce que de nos jours, c'est
l'ouverture qui engendre le succès, pas le repli caractériel sur soi
et la paranoïa.

Mais bon, ça fait tellement longtemps que je tiens le même
raisonnement que je n'espère plus être entendu.

Tout le monde dit la même chose d'AOL et pourtant, A ce jour AOL est bien
vivant....

tout le monde critique McDo mais cela a beaucoup de succès ...
tout le monde critique la télé réalité mais cela bat des records
d'audience ...
tout le monde etc etc etc ...

ce n'est pas de savoir que la connerie est la chose la mieux partagée
du monde qui doit nous résigner et nous inciter à aller au rab !!!

Antoine

--
Eric Roumégou
http://cerbermail.com/?TSoulBerPA
(cliquez sur le lien ci-dessus pour me contacter en privé)

Roumegou wrote:

Antoine a présenté l'énoncé suivant :

Je trouve ce comportement imbécile, parce que de nos jours, c'est
l'ouverture qui engendre le succès, pas le repli caractériel sur soi
et la paranoïa.

Mais bon, ça fait tellement longtemps que je tiens le même
raisonnement que je n'espère plus être entendu.

Tout le monde dit la même chose d'AOL et pourtant, A ce jour AOL est
bien vivant....

tout le monde critique McDo mais cela a beaucoup de succès ...
tout le monde critique la télé réalité mais cela bat des records
d'audience ...
tout le monde etc etc etc ...

ce n'est pas de savoir que la connerie est la chose la mieux partagée
du monde qui doit nous résigner et nous inciter à aller au rab !!!

OK, ce sont tus des cons, mais pas vous....

Antoine

"Antoine" <antoine.info.dev@free.fr> écrivait news:40f9995d$0$29374
$626a14ce@news.free.fr:

Roumegou wrote:

Antoine a présenté l'énoncé suivant :

Je trouve ce comportement imbécile, parce que de nos jours, c'est
l'ouverture qui engendre le succès, pas le repli caractériel sur soi
et la paranoïa.

Mais bon, ça fait tellement longtemps que je tiens le même
raisonnement que je n'espère plus être entendu.

Tout le monde dit la même chose d'AOL et pourtant, A ce jour AOL est
bien vivant....

tout le monde critique McDo mais cela a beaucoup de succès ...
tout le monde critique la télé réalité mais cela bat des records
d'audience ...
tout le monde etc etc etc ...

ce n'est pas de savoir que la connerie est la chose la mieux partagée
du monde qui doit nous résigner et nous inciter à aller au rab !!!

OK, ce sont tus des cons, mais pas vous....

Antoine

Le débat dérive,

D'un point de vu plus techniques plusieurs solutions pourtant...

Mais avant tout un rappel, pour faire du temps réel sur des liaisons
"lentes" de ce type, il faut que l'application soit prévue pour un accés
réseau lent (utilisation de vues et requêtes). Il faut diminuer au
maximum le nombre d'accés au réseau.

Les principales erreurs de programmation à ne pas faire :
* HFiltre + HLitPremier + HLitSuivant ..... MAIS.... HCréeVue ou
HExécuteRequete
* Table fichier sur un fichier ..... MAIS.... Table fichier sur vue ou
requête OU table mémoire remplie par une vue ou requête

- Solution avec hyper file : Le RPC
C'est pas Hyper-Extra rapide, mais si on l'utilise bien on peut faire des
vues et requêtes qui s'exécute rapidement, même en réseau lent. Et dans
ce cas de modif en cascade cela ne devrait pas être plus long car tout
s'exécute sur le réseau où se trouve les données (je dis ne devrais car
je n'utilise pas les modif en cascade, je les programmes).

En plus un version c/s de hyper file est annoncée pour cette année, cela
devrait encore améliorer les choses.

- Autre solution avec hyper file : le composant internet sécurisé
C'est un peu plus compliqué à mettre en oeuvre dans uune application,
mias cela permet de pallier à des problèmes de fire wall. toutefois une
fonctionnalité interressante : les procédures stockées. Il faut espérer
que le c/s hyper file les integrera

- Autre solution en utilisant une autre base de données (MySQL)
C'est aujourd'hui possible car les ordres H... fonctionne sur MySQL, à
quelques modif mineurs pres dans l'application. Par contre attention
MySQL ce n'est pas gratuit, sauf si on fait du open source.
Alors si le client n'est pas prés a invetir dans une solution TSE (la
meilleur solution de mon point de vu), pourquoi serait-il prés à investir
dans une solution MySQL ?

- Solution TSE : Un investissemernt rentable ici
Dans ce cas la solutio TSE me semble être un investissement rentable. Tu
dis 2500 euros. Combien de temps avec vous déjà passé à faire des
recherches et combien de temp à coder des cas spécifiques pour gérer ce
cas ? et combien de temps faut-il encore pour finir de tout coder ?
Et enfin à combien estimez-vous une heure de tavail ?
Faite le calcul vous même.


Enfin, sur un tout autre point concernant le fait de choisir hyper file
avec windev, personnellement j'y vois plusieurs avantages :
- Pour des petites structures (moins de 5 postes), je me vois mal
proposer une solution avec un c/s payant (rappel, même MySQL est payant)
qui de plus va monopliser une machine.
- Pour la modification de stucture des données cela se fait tout seul
- hyrper file a bien évolué. Il commencer à devenir un peu juste, mais
depuis windev 7 les limites ont bien évoluées ainsi que les possibilités
sql. Avec le développement d'internet et des solutions distantes ont
commence à voir les nouvelles limites (même si on a le RPC), mais une
version c/s est annoncé pour cette année.

Voilà mon popint de vu et quelques solutions (testées avec succé)

--
En esperant t'avoir aidé.
ted

Adrien <adrien.titou@ifrance.com> wrote in message news:<mn.85317d47f5efe4b2.15079@ifrance.com>...

Arnaud DESMAZES avait soumis l'idée :
> Bonjour,
>
> comme le sujet est assez évocateur, j'en viens au faits de suite.
>
> je développe une application de gestion commerciale pour l'un de mes
> clients. Le gros problème est qu'il vient d'ouvrir une agence à 500 km
> du siège. Voici la configuration :
>
> ----------- ----------
>> SIEGE | <------ LS 256 K (VPN) -------> | AGENCE |
>> SRV_SIEGE| | SRV_AG |
> ----------- ----------
> * 15 PC * 2 PC
> * 4 PORTABLES * 2 PORTABLES
>
> Entre temps, l'idée de pouvoir embarquer une copie de la base sur les
> portables est apparue. Je me suis dit :" Heureusement, la réplication
> est là ! " Bien mal m'en a pris puisque j'essaie, en vain, de trouver
> la réplication dans l'exemple WD7 Replication de la LST 52.. Là n'est
> pas le débat, revenons à mon problème.
>
> La connexion en temps réel entre l'agence et le siège sur
> l'application est impossible car le temps d'accès à la fenetre
> d'identification de la base approche les 5mn !
> La base compte 30 fichiers HF. L'agence et les machines qui lui sont
> rattachées n'ont le droit de modifier/supprimer des enregistrements
> que sur 6 fichiers de la base, par contre ils peuvent consulter
> l'ensemble des 24 autres.
>
> Scénario :
> L'ensembles des 17 PC et des 6 Portables saisissent des informations
> au quotidien. Les portables ont le choix d'etre en mode "connecté" ou
> "autonome" ainsi ils récupèrent l'etat le plus récent de la base de
> données sur le serveur qui leur est dédié.
> Chaque nuit, les serveurs SRV_SIEGE et SRV_AG se synchronisent afin de
> mettre à jour les informations saisies par l'ensembles des postes. La
> journée le serveur de l'agence a une copie de la base de données de la
> veille. Les postes clients de l'agence travaillent sur cette copie.
> Les portables doivent pouvoir mettre à jour le serveur à tout moment
> (ou peut etre celà va t il générer des blocages dans les fichiers ?)
>
> Avez vous une idée de la marche à suivre afin de mettre ce scénario en
> place ?
> Dans l'analyse, dois je gérer la réplication pour 6 ou 30 fichiers ?
> L'outil WDReplic peut il m'aider ou dois je gérer complétement la
> replication "à la main" ? Les identifiants des 6 fichiers sont pour
> l'instant sur 8 octets et sont déclarés en tant qu'identifiants
> automatiques.
>
> Je ne sais pas si je suis très clair dans mes propos mais j'ai
> vraiment besoin d'une solution étant donné que c'est pour un
> client....J'hésite, cependant, à me tourner vers la hotline gratuite
> pour ce problème "pas assez précis".
>
> Merci d'avance pour votre aide.
>
> Cordialement,
>
> Arnaud DESMAZES

Salut,

As tu regardé dans la lst 54 ou 55. il y a un exemple de réplication
sympa.

A+
Adrien.

Salut Adrien,

j'ai beau parcourir le sommaire des 2 LST, je ne trouve rien qui
correspond, merci quand meme.

Arnaud