Hyperfile de windev v5.5
Hyperfile de windev v7.5 et + (7.5, 8, 12 et 15)
J'ai utilsé la connexion ODBC sur SQL server pour tester et ça a marché sans problème.
Hyperfile de windev v5.5
Hyperfile de windev v7.5 et + (7.5, 8, 12 et 15)
J'ai utilsé la connexion ODBC sur SQL server pour tester et ça a marché sans problème.
J'utilise hyperfileSQL.
J'ai mis le HF, car c'est le support de développement
Maintenant je me demande le nombre de lignes à modifier si je désigne un autre serveur.
j'ai trouvé l'index Full-Text très intéressant.
j'ai trouvé la création automatique de table au premier enregistrement très intéressant.
j'ai voulu faire un HChangeConnexion vers Mysql après avoir savamment charger le connecteur natif MySQL pour WD15 (il suffit de changer dans une adresse "16" par "15") à cause de la syntaxe MATCH AGAINST,
et j'ai pleuré ! ....
HAjoute ne marche pas quand la table n'est pas créée ! et HCreation, ne marche pas non plus!
avec mes 1 ans de WD je suis surpris que votre fidélité soit passée à coté d'un truc aussi basique ; et de tant d'autres !
Heu la petite note ++ : le site de Mariah Carey, il est fait avec WebDev ?
Bonsoir,
pour un usage personnel, j'utilise le plus souvent HF, cependant j'ai voté SQL Server, pour les besoins de l'entreprise dans la mesure ou il est le plus utilisé je pense.
Salutation.
Bonsoir, actuellement j'utilise HF c/s, mais je me tourne petit à petit sur PostgreSQL qui commence à prendre de l'ampleur. Espérant qu'il restera toujours Open-source
J'utilise PostgreSQL à cause de sa licence
Mais le driver que propose Windev est assez limité!
La récupération des messages Personnel envoyé par le serveur (RAISE EXCEPTION , NOTICE,... ). C'est messages ont pour code P0001
HFSQL n'est pas portable
Code : Sélectionner tout - Visualiser dans une fenêtre à part
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
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80 --trigger pour ajouter -- supprimer un utilisateur -- supprimer un contact---sur enregistrement de personne CREATE OR REPLACE FUNCTION f_ajout_utilisateur () RETURNS TRIGGER AS $$ DECLARE nom_util TEXT; mdp TEXT; a INTEGER:=100000; b INTEGER:=999999; id_groupe INTEGER; niv INTEGER; total INTEGER; groupe groupe_utilisateur; admin BOOLEAN; BEGIN IF (TG_OP='INSERT') THEN SELECT count(*) INTO total FROM loggin; IF total>0 THEN niv:=1; groupe:='Visiteur'; admin:='f'; ELSE niv:=0; groupe:='Informatique'; admin:='t'; END IF; nom_util ='U'||((random()* (b-a))::INTEGER + a )::TEXT; mdp ='P'||((random()* (b-a))::INTEGER + a )::TEXT; SELECT * INTO id_groupe FROM groupeutilisateur WHERE c_nomgroupeutilisateur=groupe; IF FOUND THEN INSERT INTO loggin (c_idlogin,c_login,c_motdepasse,c_idpersonne,c_niveau,c_admin,c_expire,c_track,c_idgroupeutilisateur,c_active) VALUES (DEFAULT, nom_util, mdp, NEW.c_idpersonne, niv, admin, 'f', NEW.c_track, id_groupe,'t'); RAISE NOTICE 'Vos codes d''accès à l''application: Utilisateur: % Mot de passe: %',nom_util,mdp; ELSE RAISE EXCEPTION 'Groupe Visiteur introuvable'; END IF; END IF; IF (TG_OP='DELETE') THEN --Suppression du TRIGGER f_interdire_suppression_loggin----------------------- DROP TRIGGER IF EXISTS interdire_suppression_loggin ON loggin; -----------Fin et suite de l'opération ---------------- DELETE FROM loggin WHERE c_idpersonne=OLD.c_idpersonne; -------Creation du TRIGGER----------------------------- CREATE TRIGGER interdire_suppression_loggin BEFORE DELETE ON loggin FOR EACH ROW EXECUTE PROCEDURE f_interdire_suppression_login (); ------------------------------------------------------- RAISE NOTICE 'L''accès à l''application a été supprimé pour Id: % Nom: % Prénoms: % ',OLD.c_idpersonne,OLD.c_nom,OLD.c_prenoms; DELETE FROM contact WHERE c_idpersonne=OLD.c_idpersonne; RAISE NOTICE 'Les contacts de : % Nom: % Prénoms: % ont été supprimés',OLD.c_idpersonne,OLD.c_nom,OLD.c_prenoms; RETURN OLD; END IF; RETURN NULL; END $$ LANGUAGE 'plpgsql';
j'utilise Oracle et j'en suis satisfait je n'aime pas hyperfile car il n'est pas standard .
Bonjour,
Après quelques mois d'un amour nouveau et exclusif pour HF la vision retrouvée je continue à utiliser HF pour de petites appli...
Après quelques années d'une collaboration encore enthousiaste avec WD je continue à utiliser HF en client serveur pour de petites appli, HF classic pour de mini appli de quelques tables. Nous sommes passés à PostgreSQL pour des appli plus musclées (plus rapide, plus strict, plus léger, plus compatible, gratuit...)
J'utilise l'analyse pour modéliser et pour l'auto-completion dans le code.
MAIS je commence mon projet par "fermeAnalyse()"
je redéclare mes connexions et je passe mes requêtes en SQL.
Plus souple et moins d'erreurs au final.
Evidement j'ai définitivement abandonné l'éditeur de requête... ingérable !
Hyperfile mais c'est vraiment pas mon choix...
Pour avoir travailler sous Oracle/MySQL/SQLServer.... je pleure... norme SQL à moitié implémentée... tout est fait pour inciter les dévs à ne pas faire de SQL ce qui engendre des comportements douteux et manque de culture BDD... à mon humble avis !
Les seuls plus pour moi : l'install est fastoche et c'est gratuit !
Comme dirait un certain Michel : "HF n'est pas gratuit, il est intégré"
On me demande d'utiliser Hyperfile puis HyperfileSQL (C/S) depuis pas mal de temps et en mode hxxxx majoritairement.
J'ai pu développer une certaine maitrise des contextes HF pour gagner en efficacité de manière parfois surprenante, principalement grâce à une gestion habile des alias et autres fichiers temporaires.
J'évite la comparaison aux autre bases qui sonne comme un conflit de clocher... Les arguments massue que sont l'intégration ajouté aux modifications automatiques se suffisent généralement mais de moins en moins à mesure qu'on avance.
Je pense que la connaissance de la base et donc qu'une conception/programmation adaptée est une nécessité.
Le support d'une autre base demande de passer en full SQL et je redoute alors la dégradation du temps de réalisation d'opération parfois rendues simple en HF.
Si j'ai le choix => SQL SERVER (possibilité, perf, prix, simplicité, image,ouverture)
Après si on a pas le choix, on fait avec
Bonjour,
Si j'avais à faire ce choix, je serais très perplexe. Développeur amateur [ce n'est pas ma profession], j'ai acheté une licence WD 18. J'ai utilisé il y a quelques années WD 7.5 et WB 7. Le HF C/S n'existait pas alors et j'avais opté pour le connecteur natif MySQL sur des bases hébergées.
J'ai donc redécouvert Windev et porté mon premier choix sur HF C/S... (un serveur HF17 Linux 64 bits dédié hébergé). Je me suis rapidement convaincu que seules les hExecuteRequeteSQL pouvaient me convenir malgré quelques oublis du langage HyperFileSQL... ou pour parler plus clairement, j'ai éliminé toutes les autres approches (hLit, hLitPremier, Suivant, Dernier, Recherche...). Je n'utilise pas l'éditeur de requêtes.
J'ai rencontré divers problèmes dont plusieurs qui m'obligeraient à très sensiblement modifier ma manière de travailler si je décidais de développer mes programmes avec cet AGL :
- 1. Impossibilité d'ouvrir en simultané plusieurs connexions. Lorsqu'on travaille sur deux bases en même temps [celle de l'applicatif par exemple, et celle du Développeur pour le signalement des bugs en parallèle], la gestion des tables fichiers (et des fenêtres qui les contiennent) est lourdement impactée si vous avez l'habitude d'utiliser OuvrirSoeur...
- 2. A partir d'une analyse.wdd, la création des hAlias est possible au prix d'une gymnastique bien compliquée. Mais le transfert (la redéclaration) des intégrités référentielles sur ces derniers me semble impossible malgré tous les efforts engagés et les nombreuses heures consommées. On peut s'en passer mais dans ce cas, au niveau du code, l'impact est très significatif. A ce niveau, je ressens un énorme manque, une frustration même : on devrait pouvoir créer par le langage SQL l'équivalent des tables (CREATE TABLE), définir des clés étrangères, leurs contraintes... Il est vrai qu'alors on se priverait des mises à jour automatiques des versions des fichiers... mais je dois dire que cette fonction me complique plutôt la vie. "Ailleurs", on apprend à vivre sans... et même très bien ! Quand un hAlias est oublié lors d'une génération... la gymnastique revient. Tant autant que celle imposée par la singularité du vocabulaire : en SQL, on utilise des tables, pas des fichiers.
- 3. L'impossibilité d'utiliser WdMap sur les hAlias (le serveur hébergé n'étant pas accessible par le protocole SMB). Alors là, c'est la galère !
L'autre solution serait donc d'utiliser les connecteurs natifs (pgSQL en ce qui me concerne). Dans ce cas, les impacts sur mes habitudes sont presque aussi nombreux et lourds de conséquences :
- 1. A priori, pas de connecteurs natifs en 64 bits. On m'épargne l'habituel refrain : "un programme 64 bits cela ne sert à rien. Le 32 suffit sur une station 64 bits, c'est bien... et même, cela "tourne" plus vite." C'est évident, d'ailleurs depuis l'avènement du 32, on est resté au 16... et même pour que cela aille encore plus vite... certains persévèrent en 8 bits !
- 2. Beaucoup plus pénalisant, dans l'état de mes connaissances actuelles, la remontée des erreurs renvoyées par le serveur me semble impossible. Mais je ne demande qu'à apprendre ! PostgreSQL dispose de sa propre nomenclature d'erreurs, ses propres codes. Et je n'arrive pas à les récupérer lors d'un doublon, d'un verrou déjà posé, d'une erreur d'intégrité...
Ce que j'ai réussi à faire pour l'instant avec le connecteur natif correspond à ce que je faisais avec Windev 7.5 et son connecteur MySQL 32 bits (pas de 64 à l'époque), sans récupération de code d'erreur du serveur... Mais cela fait longtemps (2002). Et il est très dommage, à mon sens, que le HF C/S n'ait pas évolué (encore suffisamment) vers d'autres SGDBR C/S et soit resté trop "lié" au vieil "HyperFile Classic"... certainement pour utiliser la même terminologie et ne pas dérouter les habitués...
Ceci dit dans mes deux approches (connecteur natif et HF C/S), il est possible de travailler proprement avec des méthodes de contournement que je trouve extrêmement lourdes d'autant que la factorisation de codes (on peut le réduire avec les indirections, il est vrai) ou l'équivalent d'"include" ne sont pas disponibles. Je sais bien qu'une période d'adaptation est nécessaire et que chaque solution a ses contraintes et ses avantages. Mais même si le résultat est fonctionnel et solide (me semble-t-il pour ce dernier point avec le peu de recul que j'ai), je me sens un peu à l'étroit dans ces gestions de BDD proposée par l'AGL et... dérouté. Cet aspect vraiment non négligeable de l'AGL signalé, hormis un petit bémol concernant dans certaines situations la gestion des images (l'exploitation des flux notamment dans les tables mémoire car comme pour les BDD, l'approche est trop orientée SMB au détriment des flux : on a besoin de l'adresse physique du fichier sur le disque qui contient l'image), je trouve superbe le "reste" du produit !
Cordialement. Gilles
Dernière modification par Invité ; 22/04/2013 à 19h42. Motif: Précisions et oublis
J'utilise SQL server et Hyperfile, soit chacun sur un projet différent, soit les deux ensembles, pour un même projet.
Bonjour,
J'ai utilisé Windev depuis 2008, auparavant j'ai utilisé HFSQL, mais depuis quatre ans déjà, je préfère utiliser PostgreSQL via accès natif. Et ce là marche à merveille.
HFSQL C/S n'est pas un SGBD SQL. Il n'interprête pas les ordres SQL à la volée.
Il faut donc lui lier un 'fichier d'analyse' .WDD, et si ça correspond pas à 200%... rien ne marche pas.
Je vous laisse imaginer la cata en production.
On ne peut pas 'choisir' un autre PC serveur que celui qui est décrit dans le 'fichier d'analyse': lourd
Par contre, il a l'avantage de pouvoir switcher entre HFSQL classic et C/S.
La modification de la structure des fichiers par l'interpréteur est un avantage pour faire des maquettes.
En production, c'est plutot un inconvénient-> risque de faire de grosses conneries.
La réplication est compliquée et demande beaucoup de contraintes.
Installation facile par un utilisateur néophyte.
Aucune documentation sur les performances.
MS et Linux.
Mysql / MariaDB est une solution de choix.
Souple, facile, rapide, plutôt complet, réplication facile, pas raciste, polymorphe.
Accès natif, utilise avec les ordres Hxxx
Les connecteurs mxxx.dll ont le même nom en 32 ou 64 bits. Casse pied à gérer, comme dit plus haut.
Installation plus compliquée pour le néophyte.
MS et Linux
MS Access.
Pas de C/S
Sur certaines machines, Windev reconnait toute de suite.
Sur d'autres , non.
Je suppose que cela dépend des librairies Access installées d'office sures les PC.
Très chiant à l'installation quand ça marche pas.
SQLITE
Pas de C/S
Sinon bonne surprise.
ça marche plutot pas mal pour ce que c'est censé faire.
Pas osé l'utiliser pour de moyens volumes.
@ jeanphy71 :
L'utilisation de HFSQL C/S n'oblige pas l'utilisation d'une analyse.
Si tu souhaites utiliser une analyse, autant laisser les fichiers en classic.
En ce qui concerne la déclaration d'une connexion dans une analyse, rien ne t'y oblige. Si tu en déclares une, il faut prévoir derrière, en programmation, un changement de connexion.
HFSQL C/S est gratuit, pas MySQL.
Qu'entends-tu par 'SQL à la volée' ?
Partager