Installation HyperFile Serveur 64 bits Linux

Version imprimable

25/10/2012, 14h02
Invité

Installation HyperFile Serveur 64 bits Linux
Bonjour,

J'ai utilisé Windev jusqu'à la version 7.5. J'ai un ancien programme qu'il faudrait que je réactualise. Je ne suis pas très enclin à réutiliser Windev même si je n'ai absolument rien à lui reprocher. J'en garde même un très bon souvenir. Néanmoins mes habitudes de programmation ne sont plus celles-ci.

D'un autre côté, je suppose qu'une grande partie du code serait réutilisable même si en 7.5 je ne disposais pas du CS... et dans ce cas précis, le facteur temps n'est pas négligeable.

Donc, j'essaie de faire le tour de la question. Le facteur critique pour moi est le SGDBR. Je connais globalement les possibilités d'HyperFile (enfin de la version HF7). J'ai lu des retours d'utilisateurs sur le CS. Cela me semble tout à fait compatible avec mes exigences.

Cependant, j'ai plusieurs questions relatives à Hyperfile CS notamment à son installation sur un serveur Linux :
1. J'ai lu la documentation où il est stipulé "compatible Debian 4.0"... Mais le document date peut-être ? Debian 6.0 squeeze (amd64 parce que la plupart des processeurs le sont) est la version stable actuelle.
2. J'ai lu également sur le forum que des versions anciennes des serveurs 14, 15 ne tournaient qu'en 32 bits et donc nécessitaient beaucoup de bricolages du serveur Linux pour émuler du 32 bits sur un 64... Est-ce le cas encore actuellement ?
3. En supposant que l'installation d'un serveur HyperFile soit possible sur une Debian Squeeze, où trouve-t-on les informations fiables, publiques (sans contrat spécifique) et officielles (pas de bidouilles) nécessaires ?
4. Y a-t-il des différences de codage (ie instructions non disponibles) au moment de la réalisation du programme Client s'il est en relation avec une version Windows du serveur HyperFile et une version Linux équivalente.
5. Mes serveurs Debian ne diposent pas de couches graphiques. Je suppose qu'on peut piloter le serveur HyperFile à partir d'un Client Windows sur lequel est installé "manta".
6. Dans la mesure où seule (peut-être) une version récente d'Hyperfile Serveur (17 ?) peut être "normalement" installée sur une Debian Squeeze, est-ce qu'un programme développé en Windev 12, 13,..., 16 peut se connecter à un serveur 17 et l'exploiter normalement. Autrement dit jusqu'à quelle version de Windev s'exerce la rétrocompatibilté d'un HyperFile 17 ?
Si un HyperFile Serveur ne répond pas à mes contraintes, sachant que j'utilise PostgreSQL 9 dans tous mes développements habituels, les composants natifs sont-ils compatibles avec cette version ? Je n'ai vu que des références à 8.2. Sont-ils capables de renvoyer les codes Error ?

Merci. Cordialement.
Gilles
25/10/2012, 14h25
frenchsting

Je ne connais pas Debian et encore moins manta sous linux.

Néanmoins, je peux te répondre sur certains points.
4 - Non : tu fais des requêtes au sgbd. Celui-ci te renvoie les réponses. C'est vrai pour tous les sgbd. Tu pourrais également fonctionner avec mysql/postgesql ou autres sous linux.
5 - Il y a le centre de contrôle hyperfile.
6 - Voir réponse 4. Les programmes conçus pour HF/CS penvent attaquer n'importe quel version de HF/CS.
25/10/2012, 14h59
Invité

Bonjour,

Merci pour votre réponse.

Pour le point 4, cela ne me semblait pas évident... en tout cas pour HyperFile.

OK pour le point 5.

Je ne disposais pas d'HyperFile CS en 7.5 mais j'utilisais l'accès natif mySQL. Windev a certainement fait des progrès mais de mon temps, après un SQLInfoGene, il fallait triturer le SQL.MesErreur pour en extraire le numéro de l'erreur... parce que le SQL.Erreur était euh... laconique et imprécis. Ceci dit c'était exploitable. Le tout est de savoir si cela fonctionne en PostgreSQL et surtout si le connecteur natif est compatible 9. La version 8 nécessitait une ribambelle de dll associées. En 9, 5 dll suffisent. Donc pour les méthodes utilisées pour le retour des erreurs, il y a certainement des différences.

Pour la rétrocompatibilité, je suis un peu étonné. Il me semble avoir lu que des accès à HF CS 17 à partir d'un programme développé en Windev 16 avait posé problème. Peut-être un défaut de jeunesse, corrigé depuis.

Le problème c'est que j'ai besoin de certitudes. Je veux savoir si cela fonctionne et non pas s'il est prévu ou annoncé que cela fonctionne. Cela a toujours été pour moi une subtilité Windevienne.

Gilles
25/10/2012, 15h25
frenchsting

Disons simplement que la version 17 n'est pas la plus performante. Tu peux utiliser les versions antérieures si tu as la v17.
HF/CS est sorti pour la version 9 (et ne fonctionnait pas très bien)...
A partir de la version 12, ça marche plutôt bien. Tout dépend de ce que tu veux faire et notamment du volume de données et de la complexité de tes requêtes.
Tu pourrais très bien installer un autre sgbd (mysql, postgresql,..) sur ton serveur debian et utiliser l'accès natif qui va avec.
25/10/2012, 16h02
Invité

Pour le SGDBR, le volume on s'en moque un peu. Je dois gérer le transactionnel, les verrous (ponctuellement) et un retour fin d'erreurs. Evidemment sous oublier l'intégrité référentielle donc les clés étrangères (d'où le retour fin d'erreurs).

Si Windev est en course, la rapidité n'est pas un argument non plus (du moins pas plus que la volumétrie) à condition que le FetchRow fonctionne correctement pour des SQLTable par exemple. Je n'utiliserai que les fonctions SQL (jamais les Hlitxxx beaucoup trop lointaines de mes habitudes).

Le serveur PostgreSQL (serveur dédié hébergé) est déjà installé en production (et en redondance). Si j'installe l'HyperFile cela sera sur l'un des serveurs. Mais il est hors de question que je mette du 32 bits sur mon amd64 et que j'installe "en concurrence" des dépendances obsolètes comme je l'ai lu dans certains messages.

Cordialement. Gilles
25/10/2012, 16h25
frenchsting

Windev fait du transactionnel pour le CS.
Pour la programmation, le SQL est le bienvenu mais comme je le disais, pas trop complexe. Le SQL windev n'est pas le "vrai" SQL. Des retours de requêtes pourront te surprendre...

Quand à la version x64, le plus simple serait d'en installer une version d'essai.
25/10/2012, 16h32
Invité

OK merci pour tous ces renseignements.

Si je bricole un de mes serveurs, le gain de temps que me procurerait la réutilisation des codes de l'ancien programme va être cannibalisé par les tentatives d'installation, de corrections, de mise au point... et de remise en état initial du serveur en cas d'échec.

Voilà pourquoi je demande sur ce forum un retour d'expérience. La question reste donc ouverte.

Citation:

Envoyé par frenchsting

Disons simplement que la version 17 n'est pas la plus performante. Tu peux utiliser les versions antérieures si tu as la v17[...]

Par contre, j'ai compris à demi-mots que la version de HyperFile conseillée selon votre expérience est la 16. C'est cela ? Ce n'est pas écrit mais je suppose que la plus aboutie est la dernière avant la 17 :D. C'est très "windevien" comme formulation... Si je m'y remets, il va me falloir un temps d'adaptation. ;) Encore merci pour tous ces renseignements.

Cordialement. Gilles
31/10/2012, 16h59
Invité
Bonjour,

je fais un petit CR comme j'ai l'habitude dans mon forum habituel sur la réponse à la question posée.

Sur les conseils de Frenchsting, j'ai téléchargé WD170PACKEXPRESS079e.exe et WX170PACKHFSQLCS078g.exe.

J'ai décompacté sur un Windows 7 le fichier WX170PACKHFSQLCS078g.exe et récupéré les 3 fichiers du dossier Linux44_64
- manta_install64
- mantainstall.zip
- README
Je les ai déposés dans le répertoire /root du serveur Linux puis me suis connecté en root
Code:

1 2 3 4 chmod 770 manta_install64 chmod +x manta_install64 chmod 770 mantainstall.zip ./manta_install64
J'ai fait 3 tentatives sur un serveur de test LeNovo ThinkServer TS200v
- La première avec une Debian Squeeze 6.0.5 server amd64. C'est un échec. L'erreur signalée dans le terminal est "Fichier binaire impossible à lancer". Une petite recherche sur Internet ne m'a pas permis de régler le problème mais a proposé une solution simple pour une autre distribution "proche" : http://tadidio.blogspot.fr/2012/03/o...iric-1110.html
- Donc la seconde avec une Ubuntu 11.10 [ubuntu-11.10-server-amd64.iso]. Effectivement avec succès comme indiqué dans le blog. Le noyau de la 11.10 est plus récent que celui de la Squeeze. Est-ce l'explication ? Ou faut-il plutôt chercher un défaut d'installation de "dépendances" ? (ou les deux ?) Invérifiable puisque manta_install64 n'est pas un exécutable dynamique mais statique si l'on en croit ldd.
  D'un autre côté, installer une 11.10 est une aberration à moyen terme.
- Donc troisième tentative avec une 12.04 LST amd64 [ubuntu-12.04.1-server-amd64.iso]. Egalement un succès. Installation directe et aussi facile que pour la 11.10.
Je vous remercie pour l'aide apportée. Je réfléchis à cette solution ponctuelle sachant maintenant que techniquement un serveur Linux 64 récent peut héberger un serveur HyperFile17. Reste maintenant à collecter pour les évaluer des informations sur les performances exactes d'HyperFile (j'ai lu des propos parfois alarmistes, en tous cas ayant attiré mon attention) et les comparer à mon SGDBR actuel dans le cadre d'une exploitation à partir de Windev. Parallèlement, je vais essayer le WD170PACKEXPRESS079e.exe plus en profondeur. Mais je ne sais pas encore si la version Express va me permettre de créer des tables d'ampleur suffisante pour tester par exemple le FetchRow, les tris, les jointures, ou la possibilité d'utiliser le connecteur natif PostgreSQL... Mais je vais essayer, il y a nécessairement quelque chose à en apprendre.

Cordialement. Gilles
02/11/2012, 09h25
frenchsting

Bonjour,

Merci pour ton compte-rendu détaillé comme il faut.

Je te conseille de créer un tout petit projet qui va "attaquer" ton serveur C/S, et valider ainsi ton install.
Tu crées un nouveau projet avec une analyse. Dans cette analyse, un table personne (id, nom, prenom).
Une fenêtre qui te permet de saisir des noms et des prénoms.
Une deuxième fenêtre avec une table liée à ton fichier qui permetra de visualiser tes saisies.
Rien d'esthétique là-dedans, juste la vérificatin du bon fonctionnement... ;)

Bonjour,

C'est fait... et j'ai encore besoin d'aide

J'ai créé une base, une table de test sur un serveur distant (hébergé) et donc je me suis mis en local avec une connexion Wifi lente. Donc dans des conditions dégradées.

Donc ma table (fichier) test contient 2 champs uniques, teID et teNOM, une chaine 20 et une 50. J'ai construit ma table avec l'analyse.
Ma connexion est définie ainsi
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 ghfConnexion est une Connexion // Paramètres de la connexion ghfConnexion..Provider = hAccèsHFClientServeur ghfConnexion..Utilisateur = "hfUser" ghfConnexion..MotDePasse = "xxxxxxxxxx" ghfConnexion..Serveur = "xx.xx.xx.xx" ghfConnexion..BaseDeDonnées = "hfBase" ghfConnexion..Cryptage = hCryptageNon ghfConnexion..Accès = hOLectureEcriture ghfConnexion..OptionsCurseur = hCurseurClient Message("Connexion en cours") SI PAS HChangeConnexion( test,ghfConnexion) ALORS Erreur("Pas de connexion") FIN HCréationSiInexistant(test) Message("Connexion réalisée") LOCAL I est un entier POUR I = 1 A 10000 test.teID = gFuncALEA_IDSTAMP() test.teNOM = gFuncALEA_STRING(50) SI HAjoute(test,hIgnoreIntégrité+hIgnoreDoublon+hBlocageNon) ALORS Message(I) FIN

02/11/2012, 09h54
frenchsting

Et c'est quoi la question ? ;)

Désolé, j'ai validé trop tôt.
Citation:
Envoyé par selzig
Bonjour,

C'est fait... et j'ai encore besoin d'aide

J'ai créé une base, une table de test sur un serveur distant (hébergé) et donc je me suis mis en local avec une connexion Wifi lente. Donc dans des conditions dégradées.

Donc ma table (fichier) test contient 2 champs uniques, teID et teNOM, une chaine 20 et une 50. J'ai construit ma table avec l'analyse.
Ma connexion est définie ainsi
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 ghfConnexion est une Connexion // Paramètres de la connexion ghfConnexion..Provider = hAccèsHFClientServeur ghfConnexion..Utilisateur = "hfUser" ghfConnexion..MotDePasse = "xxxxxxxxxx" ghfConnexion..Serveur = "xx.xx.xx.xx" ghfConnexion..BaseDeDonnées = "hfBase" ghfConnexion..Cryptage = hCryptageNon ghfConnexion..Accès = hOLectureEcriture ghfConnexion..OptionsCurseur = hCurseurClient Message("Connexion en cours") SI PAS HChangeConnexion( test,ghfConnexion) ALORS Erreur("Pas de connexion") FIN HCréationSiInexistant(test) Message("Connexion réalisée") LOCAL I est un entier POUR I = 1 A 10000 test.teID = gFuncALEA_IDSTAMP() test.teNOM = gFuncALEA_STRING(50) SI HAjoute(test,hIgnoreIntégrité+hIgnoreDoublon+hBlocageNon) ALORS Message(I) FIN
Ceci fait, dans une autre fenêtre, j'ai associé une tablefichier au fichier... et lancé le programme.
D'abord stupéfaction : connexion réussie au bout de 6 secondes ! Compte tenu de la liaison, c'est correct. Mais mieux, à l'ouverture de la fenêtre contenant la tablefichier : les premières lignes sont immédiatement lisibles. Le Fetchrow fait ensuite son travail proprement. Là où cela ne va plus, c'est à l'utilisation des ascenceurs dans la table...

Je n'ai pas pu comparer avec les connecteurs natifs. Par contre, une table identique sur un serveur PostgreSQL hébergé sur le même serveur, pilotée par un programme en Lazarus, crée nettement plus vite les 10000 lignes (un facteur 10), mais se connecte et charge une dbGrid dans un temps à peu près équivalent. En Lazarus, le fonctionnement des ascenceurs dans une liaison dégradée pose le même problème.

Aussi, j'utilise des StringGrids (Table mémoire) avec un FetchRow sur le connecteur. Concrètement, si l'utilisateur ouvre la fenêtre, la table est partiellement remplie, une centaine de lignes, puis en "thread", le remplissage continue, laissant alors la possibilité à l'utilisateur de commencer à créer immédiatement un nouvel enregistrement par exemple.

C'est là que j'ai besoin d'aide : J'ai créé en Windev une autre fenêtre contenant une tablememoire.... puis j'ai utilisé la méthode conseillée dans l'aide
Code:

1 2 3 4 5 6 7 8 9 10 11 // Transfert dans table : récupération par Fetch ResSQL = SQLExec("SELECT teID, teNOM FROM test", "REQ1") SI ResSQL ALORS // Récupération par groupe de 100 lignes TANTQUE SQLTable(100,"REQ1","testTABLE") // Traitement SINON // Erreur SQL FIN SQLFerme("REQ1")
Alors la table se charge mais jamais le chargement n'est threadé. Donc il faut attendre la fin du remplissage de la table ? Je m'y prends mal, forcément.

Merci. Cordialement. Gilles

02/11/2012, 10h34
frenchsting

Non, ton traitement est ok. Le remplissage est bloquant. Tu pourrais éventuellement utiliser un thread qui reprendrait ton code. Après, il faudrait que tu géres les clics sur la table pendant le remplissage.

Ce qu'il faut que tu fasses, plutôt, c'est, lorsque tu crées ta table, l'associer à ta requête...

Rebonjour Frenchsting,

j'ai essayé votre méthode avec la déclaration de la requête dans la Tablefichier (si j'ai bien compris vos propos): le problème est inchangé.

J'ai continué avec mes TableMémoires et adapté le code Pascal que j'avais dû mettre en place pour régler ce problème avec mySQL (la libmySQL.dll ne gère pas le FetchRow), sachant qu'avec PostgreSQL, cela se fait tout seul.

Le principe est simple : Une procédure non threadée commence le remplissage de la table, puis une autre threadée prend la suite.

Le code est réparti en 2 endroits :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 GLOBAL iFetchRow est un entier PROCEDURE LoadPartWithoutThread LOCAL i est un entier ResSQL est un booléen ResSQL = SQLExec("SELECT teID, teNOM FROM test", "REQ1") SI ResSQL ALORS TableSupprimeTout(Table1) i = 0 TANTQUE (SQLAvance("REQ1") = 0) ET (i < iFetchRow) i++ TableAjouteLigne(Table1, SQLLitCol("REQ1", 1), SQLLitCol("REQ1", 2)) Multitâche() FIN SQLFerme("REQ1") FIN LoadPartWithThread() PROCEDURE LoadPartWithThread() LOCAL i est un entier Message("Thread lancé") ResSQL est un booléen = SQLExec("SELECT teID, teNOM FROM test", "REQ2") SI ResSQL ALORS i = 0 TANTQUE (SQLAvance("REQ2") = 0) i++ SI i > iFetchRow ALORS TableAjouteLigne(Table1, SQLLitCol("REQ2", 1), SQLLitCol("REQ2", 2)) Multitâche() FIN SQLFerme("REQ1") Message("Thread terminé") FIN
Pour PROCEDURE LoadPartWithThread() --> Paramétrer les automatismes de procédures
Combien de fois ? -> 1 fois
Quand ? -> A la fin du traitement contenant l'appel
Comment ? -> Exécution en tâche de fond (Thread) et -> Avec utilisation de HyperFileSQL (avec copie de contexte)

Comme je redécouvre Windev, plusieurs remarques :

Dommage que le FetchRow utilisé pour le remplissage des tablefichiers ne soit pas disponible (ie incorporé) pour celui des tablemémoires [Enfin je ne l'ai pas trouvé]
SQLTable est moins souple et moins rapide que SQLLit pour charger une tablemémoire. Je l'avais déjà remarqué avec les connecteurs natifs en Winde 7.5.
Avec Windev et sa fenêtre "Automatisme de procédure", l'emploi des threads est grandement facilité. Par contre, il faut espérer qu'il fonctionne réellement dans toutes les situations de manière fiable.
Il faudrait améliorer un peu le code. Je ne sais pas si LIMIT/OFFSET fonctionne en SQL sur HF/CS. L'utilisation de 2 requêtes différenciées améliorerait et simplifierait le code. De même, il faudrait vérifier que le lancement de la procédure threadée est nécessaire.
Il faut en effet comme signalé par Frenchsting, bloqué les tris des colonnes et la recherche tant que le thread n'est pas terminé... Ce qui n'empêche pas de laisser opérationnels les boutons [INS], [UPD], [DEL], [DUP]...

J'ai également vérifié le transactionnel et le blocage de ligne. C'est assez facilement fonctionnel mais requiert des surcharges par exemple pour l'interception du message d'erreur Windev (et de ré-essai) en cas de tentative de blocage d'enregistrement déjà bloqué.

Amélioration : la PROCEDURE LoadPartWithThread() (évidemment lancée dans un thread) semble se suffire à elle-même (en enlevant la condition sur iFetchRow).

Cordialement. Gilles