|
Client Serveur avec Windev9 |
Iniciado por imbert.ger, set., 19 2005 2:22 PM - 25 respostas |
| |
| | | |
|
| |
Publicado em setembro, 19 2005 - 2:22 PM |
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 ? |
| |
| |
| | | |
|
| | |
| |
Publicado em setembro, 19 2005 - 2:47 PM |
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. |
| |
| |
| | | |
|
| | |
| |
Publicado em setembro, 19 2005 - 3:50 PM |
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... |
| |
| |
| | | |
|
| | |
| |
Publicado em setembro, 19 2005 - 4:31 PM |
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 ? |
| |
| |
| | | |
|
| | |
| |
Publicado em setembro, 19 2005 - 4:45 PM |
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. |
| |
| |
| | | |
|
| | |
| |
Publicado em setembro, 19 2005 - 5:07 PM |
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 |
| |
| |
| | | |
|
| | |
| |
Publicado em setembro, 19 2005 - 5:16 PM |
Oui sauf que mes représentatnt, n'ont vont pas s'abonner à l'adsl dans chaque Hotel ou ils descendent... |
| |
| |
| | | |
|
| | |
| |
Publicado em setembro, 19 2005 - 5:34 PM |
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... |
| |
| |
| | | |
|
| | |
| |
Publicado em setembro, 19 2005 - 5:42 PM |
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. |
| |
| |
| | | |
|
| | |
| |
Publicado em setembro, 19 2005 - 5:43 PM |
| |
| |
| | | |
|
| | |
| |
Publicado em setembro, 19 2005 - 5:45 PM |
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. |
| |
| |
| | | |
|
| | |
| |
Publicado em setembro, 19 2005 - 7:23 PM |
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... |
| |
| |
| | | |
|
| | |
| |
Publicado em setembro, 20 2005 - 12:48 AM |
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...
|
| |
| |
| | | |
|
| | |
| |
Publicado em setembro, 20 2005 - 9:23 AM |
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 ? |
| |
| |
| | | |
|
| | |
| |
Publicado em setembro, 20 2005 - 9:32 AM |
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+ |
| |
| |
| | | |
|
| | |
| |
Publicado em setembro, 20 2005 - 9:38 AM |
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 ?
|
| |
| |
| | | |
|
| | |
| |
Publicado em setembro, 20 2005 - 10:04 AM |
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+ |
| |
| |
| | | |
|
| | |
| |
Publicado em setembro, 20 2005 - 10:39 AM |
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. |
| |
| |
| | | |
|
| | |
| |
Publicado em setembro, 20 2005 - 10:43 AM |
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
|
| |
| |
| | | |
|
| | |
| |
Publicado em setembro, 20 2005 - 1:10 PM |
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
|
| |
| |
| | | |
|
| | |
| |
Publicado em setembro, 20 2005 - 2:44 PM |
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. |
| |
| |
| | | |
|
| | |
| |
Publicado em setembro, 20 2005 - 6:50 PM |
"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
|
| |
| |
| | | |
|
| | |
| |
Publicado em setembro, 21 2005 - 10:49 AM |
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 ?
|
| |
| |
| | | |
|
| | |
| |
Publicado em setembro, 22 2005 - 4:36 PM |
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 ?
|
| |
| |
| | | |
|
| | |
| |
Publicado em setembro, 22 2005 - 11:11 PM |
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. |
| |
| |
| | | |
|
| | |
| |
Publicado em setembro, 23 2005 - 4:39 PM |
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.
|
| |
| |
| | | |
|
| | | | |
| | |
|