[Généralités] Quel SGBD utilisez-vous avec WinDev ? [Débat]

[frenchsting]

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.

[pompomthebest]

J'utilise hyperfileSQL.

[Laurent_m_paris]

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 ?

[tatayo]

Bonjour,

Envoyé par Laurent_m_paris

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 !

En ce qui me concerne, je ne suis pas passé à côté, vu que je n'utilise pas du tout les ordres h*, mais uniquement les ordres Sql*. Donc ce n'est pas un gros manque, dans mon cas tout du moins.

Tatayo.

[labib23dz]

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.

[miripesage]

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

[Arnaud B.]

Bienvenue au club !

Envoyé par miripesage

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

[NetLandGim]

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 :

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';

[rhabib]

j'utilise Oracle et j'en suis satisfait je n'aime pas hyperfile car il n'est pas standard .

[Atsibat]

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 !

[michel.souris]

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 !

[Emmanuel Lecoester]

Comme dirait un certain Michel : "HF n'est pas gratuit, il est intégré"

[R&B]

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.

[lmontout]

Si j'ai le choix => SQL SERVER (possibilité, perf, prix, simplicité, image,ouverture)

Après si on a pas le choix, on fait avec

[alexeyk]

Envoyé par lmontout

Si j'ai le choix => SQL SERVER (possibilité, perf, prix, simplicité, image,ouverture)

Après si on a pas le choix, on fait avec

SQL Serveur ou MySql.

Alex.

[selzig]

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