|
FORUMS PROFESSIONNELS
WINDEV, WEBDEV et WINDEV Mobile |
| | | | | |
| Client Serveur avec Windev9 |
| Débuté par Gérard Imbert, 19 sep. 2005 14:22 - 25 réponses |
| |
| | | |
|
| |
Posté le 19 septembre 2005 - 14:22 |
Grosse déception, je pensais (surement naivement) que je pouvais transposer une application HF standard en application Client/Serveur!
Pour le transfert, pas de PB, mais pour les résultats, la CATA!
Tant que l'on est en réseau, tout marche avec HFCS, temps de réponses corrects, mais dés que l'on passe sur une ligne RTC classique, alors là tout s'écroule, c'est pourtant l'objectif d'un client - serveur, être consulté, utilisé à distance.
Peut être faut-il ré-écrire complétement l'application en requête SQL, mais la certitude c'est qu'en ce qui me concerne RIEN n'est exploitable et évidemment ne parlons pas de SQL Server qui lui s'écroule déjà en réseau classique.
Attention, pas de confusion, je parle bien d'un programme écrit en standard HF avec les ordres classiques de lecture, écriture.
Quelqu'un a t'il déjà un vécu dans une appication similaire consultée à distance à partir d'une ligne téléphonique classique RTC ? |
| |
| |
| | | |
|
| | |
| |
Posté le 19 septembre 2005 - 14:47 |
Je pense qu'il ne faut pas se leurrer, il est presque impossible d'avoir des temps de réponse correctes à travers un lien RTC. Je pense que dans ce cas là Webdev s'impose, où alors une connection RDP ou Citrix.
Frédéric. |
| |
| |
| | | |
|
| | |
| |
Posté le 19 septembre 2005 - 15:50 |
En RTC, je vous souhaite bon courage.
Mais dans tous les cas il faut modifier les accès aux données pour utiliser des requêtes, qui elles s'exécuteront sur le serveur.
Le mieux est quand même de virer le RTC pour un accès ADSL... |
| |
| |
| | | |
|
| | |
| |
Posté le 19 septembre 2005 - 16:31 |
Il parait évident qu'un traitement local ou réseau diffère d'un traitement
RTC, c'est du bon sens.
Il est bien entendu nécessaire d'adapter l'application au très faible débit
de ce type de ligne.
Tu devrais regarder le site de philippe Tosello
http://freedev.windev.free.fr/Page_Client_Serveur_Optimisations.htm
Antoine
Gérard Imbert wrote:
Grosse déception, je pensais (surement naivement) que je pouvais
transposer une application HF standard en application Client/Serveur!
Pour le transfert, pas de PB, mais pour les résultats, la CATA!
Tant que l'on est en réseau, tout marche avec HFCS, temps de réponses
corrects, mais dés que l'on passe sur une ligne RTC classique, alors
là tout s'écroule, c'est pourtant l'objectif d'un client - serveur,
être consulté, utilisé à distance.
Peut être faut-il ré-écrire complétement l'application en requête
SQL, mais la certitude c'est qu'en ce qui me concerne RIEN n'est
exploitable et évidemment ne parlons pas de SQL Server qui lui
s'écroule déjà en réseau classique.
Attention, pas de confusion, je parle bien d'un programme écrit en
standard HF avec les ordres classiques de lecture, écriture.
Quelqu'un a t'il déjà un vécu dans une appication similaire consultée
à distance à partir d'une ligne téléphonique classique RTC ? |
| |
| |
| | | |
|
| | |
| |
Posté le 19 septembre 2005 - 16:45 |
J'ai le même problème d'utilisation. j'ai opté pour HF CS pour rendre accessible par nos commerciaux l'application mais le RTC c'est pas cool... J'ai donc pensé ensuite à la synhcronisation mais la encore c'est pas encore développé sous WinDev...Du coup je vois plus l'utilité de HF CS. |
| |
| |
| | | |
|
| | |
| |
Posté le 19 septembre 2005 - 17:07 |
Salut !
On 19-Sep-2005, "GUION Richard" <r.guion@gys.fr> wrote:
J'ai le même problème d'utilisation. j'ai opté pour HF CS pour rendre
accessible par nos commerciaux l'application mais le RTC c'est pas cool...
J'ai donc pensé ensuite à la synhcronisation mais la encore c'est pas
encore développé sous WinDev...Du coup je vois plus l'utilité de HF CS.
C'est peut-être un peu sévère comme jugement ... Je peux t'assurer qu'avec
une liaison ADSL, cela marche très bien ... Quasi aussi vite qu'en réseau
local !
Bien sûr, il s'agit d'adapter un peu la programmation ... Mais dans
l'ensemble ... ce n'est pas tant de travail !
--
Marcel Berman
c/o Managing Business SPRL
Allée du Petit Paris, 11
B - 1410 - Waterloo
Tel : +32 2 351.60.64
Fax : +32 2 351.45.78
Gsm : +32 475.799.477 |
| |
| |
| | | |
|
| | |
| |
Posté le 19 septembre 2005 - 17:16 |
Oui sauf que mes représentatnt, n'ont vont pas s'abonner à l'adsl dans chaque Hotel ou ils descendent... |
| |
| |
| | | |
|
| | |
| |
Posté le 19 septembre 2005 - 17:34 |
J'utilise déjà des requètes, pas de combo et tout ce qu'il faut
Pour afficher une fenêtre, il y en a pour 7 minutes...Donc non vraiment ce n'est pas négociable... |
| |
| |
| | | |
|
| | |
| |
Posté le 19 septembre 2005 - 17:42 |
L'application WebDev a déjà été développée, ce qui me gêne c'est que je ne vois pas du tout l'utilité de HF/CS qui semblait annoncée comme géniale au cours de la présentation de Windev9. |
| |
| |
| | | |
|
| | |
| |
Posté le 19 septembre 2005 - 17:43 |
| |
| |
| | | |
|
| | |
| |
Posté le 19 septembre 2005 - 17:45 |
Merci pour le bon sens, mais ce qui me gêne c'est que je ne vois pas du tout l'utilité de HF/CS qui semblait annoncée comme géniale au cours de la présentation de Windev9. |
| |
| |
| | | |
|
| | |
| |
Posté le 19 septembre 2005 - 19:23 |
Dans ce cas, on en revient au premier point, il faut adapter ton application
à tes ressources qui sont dans ce cas tres limités.
Si tu as une interface allégée, n'utilisant que des requetes, requetes qui
ne remonte que les rubriques réellement utiles et sans mémo, que tu
n'utilises aucun champ autoalimenté, que tu limites au maximum les
aller/retour entre le client et le serveur, tu dois pouvoir utiliser le
client serveur.
L'analyse de preformance est tres utile dans ce cas pour voir ou passe le
temps perdu.
Le probleme que tu rencontres ici n'est pas lié à windev, tu aurias le meme
pb avec oracle ou sql serveur.
Antoine.
GUION Richard wrote:
Oui sauf que mes représentatnt, n'ont vont pas s'abonner à l'adsl
dans chaque Hotel ou ils descendent... |
| |
| |
| | | |
|
| | |
| |
Posté le 20 septembre 2005 - 00:48 |
Avec une ligne RTC faut pas se voiler la face. c'est mission impossible !!
Mais c'est pas pour ça que le C/S n'est bon à rien.
Accès optimisé sur réseau 10/100 et ADSL 256/512
Sécurité en cas de panne de courant ou de manque de stabilité d'un poste de
gestion, etc...
"GUION Richard" <r.guion@gys.fr> a écrit dans le message de news:
432ec5e2$1@news.pcsoft.fr...
J'utilise déjà des requètes, pas de combo et tout ce qu'il faut
Pour afficher une fenêtre, il y en a pour 7 minutes...Donc non vraiment ce
n'est pas négociable...
|
| |
| |
| | | |
|
| | |
| |
Posté le 20 septembre 2005 - 09:23 |
Je ne connais pas VNC, mais si c'est le même principe que PCANYWHERE, on prend la main sur sur un PC déporté et on travaille sur ce PC, donc à quoi peut servir HF/CS ?
Je dis peut être une bêtise, mais je vois que ce sujet est un vrai pb pour beaucoup et que dans ce domaine Pcsoft est beaucoup trop discret pour définir des pré-requis.
C'est toujours génial quand on fait des petits pgms de démo, mais quand il s'agit de transposer de grosses applications existantes, on reste avec le BB sur les bras.
A quand un vrai forum sur ce sujet avec des vraies solutions ? |
| |
| |
| | | |
|
| | |
| |
Posté le 20 septembre 2005 - 09:32 |
Avant toute chose un minimum d'étude préalable est nécessaire.
Il faut en tout premier lieu mesurer le volume de ce que vous demandez. Grosso modo, le nombre d'enreg multiplié par la taille de chaque enreg. Ensuite il faut voir les spécifications de la ligne, en combien d'octets peuvent "physiquement" passer à la seconde. Il vous reste alors une division à faire pour savoir combien en théorie il faut de temps pour récupérer vos données. Attention, c'est un temps optimiste puisque les trames réseau n'acheminent pas que vos données, et il faut tenir compte de la réponse du serveur, des dispositifs de sécurité à traverser ....
Conclusion : avant de vous lancer, vérifiez que "ça passe" pour ne pas être "cassé" 
A+ |
| |
| |
| | | |
|
| | |
| |
Posté le 20 septembre 2005 - 09:38 |
Bonjour,
Pour les utilisateurs mobiles nous utilisons VNC pour les liaisons RTC ou
pcanywhere selon le cas
il y a aussi des inconvénients mais il ne faut pas remettre cause les softs
existants
Patrick
"Gérard Imbert" <imbert.ger@wanadoo.fr> a écrit dans le message de news:
432e98f8$1@news.pcsoft.fr...
Grosse déception, je pensais (surement naivement) que je pouvais
transposer une application HF standard en application Client/Serveur!
Pour le transfert, pas de PB, mais pour les résultats, la CATA!
Tant que l'on est en réseau, tout marche avec HFCS, temps de réponses
corrects, mais dés que l'on passe sur une ligne RTC classique, alors là
tout s'écroule, c'est pourtant l'objectif d'un client - serveur, être
consulté, utilisé à distance.
Peut être faut-il ré-écrire complétement l'application en requête SQL,
mais la certitude c'est qu'en ce qui me concerne RIEN n'est exploitable et
évidemment ne parlons pas de SQL Server qui lui s'écroule déjà en réseau
classique.
Attention, pas de confusion, je parle bien d'un programme écrit en
standard HF avec les ordres classiques de lecture, écriture.
Quelqu'un a t'il déjà un vécu dans une appication similaire consultée à
distance à partir d'une ligne téléphonique classique RTC ?
|
| |
| |
| | | |
|
| | |
| |
Posté le 20 septembre 2005 - 10:04 |
PC SOFT ne peut rien définir du tout pour vous ! Quel est le volume de ce que vous devez récupérer sur le serveur (ce sont vos données vous seul avez ces informations), et combien d'octets passent sur votre ligne à la seconde ?
C'est ça la bonne question.
Il est ainsi possible d'avoir un ordre de grandeur sur les temps à attendre pour récupérer les données, et cela indépendamment de moteur.
A+ |
| |
| |
| | | |
|
| | |
| |
Posté le 20 septembre 2005 - 10:39 |
Tu peux passer sous Orable, SQL Server ou même DB2/400, tu auras le même problème avec un accès RTC.
Quel est l'intérêt du Client Serveur ? C'est assez simple:
Imaginons que je lance une grosse requête sur ma base, requête qui utilise plusieurs tables avec des critères sur des champs non indexés. Dans le cas de l'utilisation de fichiers partagés ( HF, Access... ), le poste client doit parcourir tous les indexes utilisés par la requête, et selon la requête toute les tables pour lesquels les indexes ne sont pas utilisés. Dans le cas de grosses tables, c'est plusieurs Mo, voir plusieurs Go qui transitent sur le réseau.
Dans le cas d'une architecture client/serveur, c'est le serveur qui exécute la requête. Ne transite sur le réseau que la requête et son résultat.
Coté sécurité, avec le client serveur il n'est pas nécessaire de donner un accès en lecture/écriture sur les fichiers de la base.
Dans ton cas, je te conseille de te tourner vers une solution d'accès distant, tel Citrix ou TSE. Nous utilisons les deux ( TSE pour le siège, la logistique et les magasins, et Citrix pour l'accès extérieur ). De cette façon toute nos applications sont accessible pour le personnel en déplacement, avec les mêmes temps de réponse qu'en local. Seul la vitesse d'affichage des fenêtres change en fonction de la taille du tuyau. |
| |
| |
| | | |
|
| | |
| |
Posté le 20 septembre 2005 - 10:43 |
Bonjour,
"Thierry FLENET" <t.flenet@chello.fr> writes:
Avec une ligne RTC faut pas se voiler la face. c'est mission impossible !!
Mais c'est pas pour ça que le C/S n'est bon à rien.
Accès optimisé sur réseau 10/100 et ADSL 256/512
Sécurité en cas de panne de courant ou de manque de stabilité d'un poste de
gestion, etc...
en RTC il est clair que ce n'est pas le pied, car pour chaque fenêtre,
il faut penser à optimiser (le débit des donnnés).
A condition lors de la création de l'application d'avoir toujours à
l'esprit que la limite est le réseau (il y a des outils qui permettent
de limiter ton réseau 100MB lors du développement), tu peux avoir une
applications fonctionnelles.
J'ai un CRM qui en RTC 33kb met 2 minutes à ce lancer ensuite pour
chaque fiche client c'est <1 secondes. Base 7000 clients, Contacts 30
000 etc...
Fait sous MySQL avec les accès alternatifs en SQL.
Donc rien n'est impossible si on étudie d'entré les contraintes de
chaque système.
"GUION Richard" <r.guion@gys.fr> a écrit dans le message de news: 432ec5e2$1@news.pcsoft.fr...
J'utilise déjà des requètes, pas de combo et tout ce qu'il faut
Pour afficher une fenêtre, il y en a pour 7 minutes...Donc non vraiment ce
n'est pas négociable...
--
suivre ce lien pour répondre:
http://cerbermail.com/…
Daniel
|
| |
| |
| | | |
|
| | |
| |
Posté le 20 septembre 2005 - 13:10 |
Bonjour,
"Gérard Imbert" <imbert.ger@wanadoo.fr> writes:
Je ne connais pas VNC, mais si c'est le même principe que PCANYWHERE,
on prend la main sur sur un PC déporté et on travaille sur ce PC, donc
à quoi peut servir HF/CS ?
Vous mélangez plusieurs concept. Dans votre cas afin de diminuer la
charge réseau il y a 2 solutions majeures.
La première est effectivement une base C/S à condition d'en maitriser
le principe et à mon avis de faire tout en SQL afin de ne pas
surcharger uniquement le réseau, il faut éviter les listes etc... et
surtout ne pas passer par le RAD. Dans ce cas vous allez controler
précisément la charge de votre réseau et mettre en place des
mécanismes qui sont compatibles avec son utilisation sur un réseau bas
débit. Par exemple, lors du lancement de l'application je récupère
sous forme de requête dans un tableau toutes les valeurs de mes listes
de choix (on lance l'application 1 fois/jour), et ensuite toutes mes
listes de choix dans mes écrans sont faites à partir de mes tableaux
(aucun ralentissement lors de l'utilisation).
Si vous ne voulez pas refaire votre application avec ses contraintes
il existe une solution toute faite qui est TSE ou Citrix.
Le principe est que tout se passe sur le serveur, et vous voyez
simplement une copie d'écran. Cette solution a certaine limite qu'il
faut connaître sur des réseaux lents :
- il faut éviter toute fioriture au niveau de l'application, c'est à
dire qu'il est préférable de travailler avec des fenêtres peu
chargées, eviter les tableaux, les défilement de texte etc...
- préférer des applications qui fonctionnent en 800x600 et 256
couleurs (2003 permet de passer à 64000 couleurs voire plus, mais au
détriment d'une bande passante importante).
Je dis peut être une bêtise, mais je vois que ce sujet est un vrai pb
pour beaucoup et que dans ce domaine Pcsoft est beaucoup trop discret
pour définir des pré-requis.
Oui et non. Ce n'est pas à PCSoft de fournir ce type
d'information. Lorsqu'on achète une voiture le fournisseur na va pas
tout vous expliquer car vous avez le permis, lorsque'on achète un
outil de développement c'est à nous de savoir (lecture, stage etc..)
de définir les limites. Le seul reproche qu'il peut être fait dans
l'aide c'est que PCSoft n'insiste pas suffisament sur les différents
moyens de programmation et les points fondamentaux entre une
programmation type SQL et Hlangage.
C'est toujours génial quand on fait des petits pgms de démo, mais
quand il s'agit de transposer de grosses applications existantes, on
reste avec le BB sur les bras.
A quand un vrai forum sur ce sujet avec des vraies solutions ?
--
suivre ce lien pour répondre:
http://cerbermail.com/…
Daniel
|
| |
| |
| | | |
|
| | |
| |
Posté le 20 septembre 2005 - 14:44 |
Le volume n'a rien à voir avec la bonne question lorsqu'il faut 45 secondes pour afficher une table qui contient 10 enregistrements!
Vous ne devez pas avoir fait de test sur RTC ou vous avez oublié l'objet initial de ma question. |
| |
| |
| | | |
|
| | |
| |
Posté le 20 septembre 2005 - 18:50 |
"Gérard Imbert" <imbert.ger@wanadoo.fr> writes:
Le volume n'a rien à voir avec la bonne question lorsqu'il faut 45
secondes pour afficher une table qui contient 10 enregistrements!
Bien entendu que le volume a y voir quelque chose, car elle est la
différence avec 1 réseau à 100 Mo et votre ligne en RTC si ce n'est
un problème de volume ou de débit?
Vous ne devez pas avoir fait de test sur RTC ou vous avez oublié
l'objet initial de ma question.
Ce n'est pas sympa pour les personnes qui essaient de vous aider 
Dans l'ensemble des réponses vous avez les solutions à votre
problématique, à vous de de les appliquer.
Si vous ne comprenez rien au réseau faite un stage de plomberie c'est
un bon moyen de comprendre les contraintes (débit/vitesse)
Pour l'intéret d'un client/serveur et son fonctionnement lisez un
livre sur Postgresql (ou Mysql) de chez CampusPress qui vous permettra
de voir ce qu'est un C/S.
En attendant voir http://sqlpro.developpez.com/cours/sgbdr
--
suivre ce lien pour répondre:
http://cerbermail.com/…
Daniel
|
| |
| |
| | | |
|
| | |
| |
Posté le 21 septembre 2005 - 10:49 |
Bonjour,
VNC c'est en gros PC ANYWHERE en plus simple
Effectivement vous êtes la star du forum.
Mais je pense que vous ne pouvez pas reprocher à PCSoft votre choix d'une
RTC
Car il n'offre qu'une solution de développement mais pas les supports et
votre façon de les utiliser
Il faut savoir de temps en temps revoir sa copie.
Car pour mes applicatifs, ils sont en C/S mais avec des LS 1Mo et je suis
même surpris de la rapidité.
et pour les postes qui ne peuvent en bénéficier des VNC (5 PC dédiés RTC)
c'est pas très rapide mais ça tourne sans problème
même avec déconnexions du modem (assez fréquent)
Mais il existe sûrement d'autres solutions matériel.
S'en prendre à PCSoft ne vous avancera à rien qui malgré leur coté obscure
.....
Bon DEV
Patrick
"Gérard Imbert" <imbert.ger@wanadoo.fr> a écrit dans le message de news:
432fa441@news.pcsoft.fr...
Je ne connais pas VNC, mais si c'est le même principe que PCANYWHERE, on
prend la main sur sur un PC déporté et on travaille sur ce PC, donc à quoi
peut servir HF/CS ?
Je dis peut être une bêtise, mais je vois que ce sujet est un vrai pb pour
beaucoup et que dans ce domaine Pcsoft est beaucoup trop discret pour
définir des pré-requis.
C'est toujours génial quand on fait des petits pgms de démo, mais quand il
s'agit de transposer de grosses applications existantes, on reste avec le
BB sur les bras.
A quand un vrai forum sur ce sujet avec des vraies solutions ?
|
| |
| |
| | | |
|
| | |
| |
Posté le 22 septembre 2005 - 16:36 |
Bonjour,
Basculer sur HF/CS pour une utilisation via RTC n'a en effet aucun intérêt.
En CS, on parle requête et non plus d'ordres HF avec boucles imbriquées
etc.. etc.. N'importe quel professionnel SQL vous dira que son soucis est
toujours de limiter le nombre de requêtes afin de soulager au maximum le
serveur. Il vaut mieux une requête complexe que plusieurs petites. Chaque
fois qu'un hlit* est exécuté, une requete est lancée. Le résultat est
forcément mauvais.
L'intérêt principal de basculer en HF/CS un projet avec des ordres HF
classiques est uniquement pour moi la fiabilité de la base de données. Les
risques de corruption des données suite à des arrêts inopinés de machine
n'influencent plus puisque la gestion physique des données est assurée par
le serveur et non plus par chaque poste qui ouvre les fichiers. De plus,
pour une utilisation lourde en réseau , le HF/CS devrait être plus rapide
que le HF classique.
Nous avons migré une grosse application de HF vers SQL il y a près de 3 ans
(donc avant HF/CS). La base de données choisie est SQL Server. Les résultats
sont incomparables. N'importe quelle recherche sur la base de données est
d'une rapidité sans aucune mesure avec HF classique.
Si vous voulez que vos commerciaux utilisent votre appli à distance,
dirigez-vous vers du Citrix ou du TS. Quand à l'intérêt de HF/CS ou HF, du
point de vue sécurité, je vote 100 fois pour HF/CS.
Bien à vous,
Benoit Neve
"Gérard Imbert" <imbert.ger@wanadoo.fr> a écrit dans le message de news:
432e98f8$1@news.pcsoft.fr..
Grosse déception, je pensais (surement naivement) que je pouvais
transposer une application HF standard en application Client/Serveur!
Pour le transfert, pas de PB, mais pour les résultats, la CATA!
Tant que l'on est en réseau, tout marche avec HFCS, temps de réponses
corrects, mais dés que l'on passe sur une ligne RTC classique, alors là
tout s'écroule, c'est pourtant l'objectif d'un client - serveur, être
consulté, utilisé à distance.
Peut être faut-il ré-écrire complétement l'application en requête SQL,
mais la certitude c'est qu'en ce qui me concerne RIEN n'est exploitable et
évidemment ne parlons pas de SQL Server qui lui s'écroule déjà en réseau
classique.
Attention, pas de confusion, je parle bien d'un programme écrit en
standard HF avec les ordres classiques de lecture, écriture.
Quelqu'un a t'il déjà un vécu dans une appication similaire consultée à
distance à partir d'une ligne téléphonique classique RTC ?
|
| |
| |
| | | |
|
| | |
| |
Posté le 22 septembre 2005 - 23:11 |
Merci pour cette réponse claire et objective.
C'est vrai que ma 1ére interrogation était "que peut m'apporter HFCS en l'état dans une application existante", sans ré-écriture de requêtes car nous avons une application déjà très "lourde".
Certains de nos clients utilisent effectivement Citrix et Tse, nous avons également développé une application Webdev.
Le seul constat positif dans l'état actuel de nos programmes est de pouvoir dire OUI cela marche en HfCs et NON cela ne marche pas avec SQL Server car les temps de réponse ne sont pas acceptables et je retiens bien sur la notion de fiabilité et de sécurité en HF/CS.
Maintenant à nous de ré-écrire notre application dans une optique SQL.
La migration que vous avez faite vers SQL a nécessité pas mal de ré-écriture ? ou basez vous vos observations sur de l'existant ?
Ce qui me chagrine c'est qu'une table toute simple (avec hes ordre HF...) qui affiche une dizaine d'enregistrements prennent prés de 30 sec sous SQL alors que c'est immédiat en HF et HFCS.
Apparamment vous n'avez jamais constaté de telle lenteur ?
Cordialement.
Gérard. |
| |
| |
| | | |
|
| | |
| |
Posté le 23 septembre 2005 - 16:39 |
Bonjour,
Le projet migré chez nous venait de Windev 5.5 et comportait environ 700
fenêtres + les états. Nous avons opté pour un mélange de SQL pur et d'ordres
HF.
Les fiches sont restées en HF. Toutes les fenetres de recherche (vis, tab)
ont été passées en SQL. Le mélange nous donne entière satisfaction.
La réécriture s'est faite en deux temps. Tout d'abord, juste faire
fonctionner le projet en l'état. Lorsque le fonctionnement est correct sur
la base SQL, nous passons les fenêtres une à une en SQL. Nous avons
également transposé en T-SQL certaines procédures. Par exemple, la recherche
du montant payé d'une facture (Accès au fichier caisse et recherches des
paiements) ou la mise à jour d'un stock. Nous avions pas mal de triggers et
en avons migré certains. Il faut faire attention pour la gestion des
blocages qui n'est pas évidente.
Je suis étonné que l'affichage d'une dizaine d'enegistrement prennent 30
secondes. Il y a visiblement un problème de configuration. Il faut bien
véifier que vos indexes ont été correctement créés. Si ce n'est pas le cas,
les résultats sont catastrophiques.
Dans tous les cas, sachez que la décision de migrer a été difficile à
prendre mais que la seule chose que nous ayons regretté est de ne pas
l'avoir fait plus tôt. De plus et j'en terminerai pas ceci, le fait d'avoir
quitté HF pour aller vers MS-SQL nous a rapporté plusieurs clients qui ne
voulaient pas d'une base de données jugée inconnue voir même d'amateurs par
les milieux professionnels.
Cordialement,
Benoit Neve
"Gérard Imbert" <imbert.ger@wanadoo.fr> a écrit dans le message de news:
4333096f$1@news.pcsoft.fr...
Merci pour cette réponse claire et objective.
C'est vrai que ma 1ére interrogation était "que peut m'apporter HFCS en
l'état dans une application existante", sans ré-écriture de requêtes car
nous avons une application déjà très "lourde".
Certains de nos clients utilisent effectivement Citrix et Tse, nous avons
également développé une application Webdev.
Le seul constat positif dans l'état actuel de nos programmes est de
pouvoir dire OUI cela marche en HfCs et NON cela ne marche pas avec SQL
Server car les temps de réponse ne sont pas acceptables et je retiens bien
sur la notion de fiabilité et de sécurité en HF/CS.
Maintenant à nous de ré-écrire notre application dans une optique SQL.
La migration que vous avez faite vers SQL a nécessité pas mal de
ré-écriture ? ou basez vous vos observations sur de l'existant ?
Ce qui me chagrine c'est qu'une table toute simple (avec hes ordre HF...)
qui affiche une dizaine d'enregistrements prennent prés de 30 sec sous SQL
alors que c'est immédiat en HF et HFCS.
Apparamment vous n'avez jamais constaté de telle lenteur ?
Cordialement.
Gérard.
|
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|