Discussion :

[raf1987]

Bonjour à tous,

Je suis chargé de chercher le meilleur environnement de développement possible pour le service Ingénierie de mon entreprise.

Pour cela, j'aurais besoin de l'avis de professionnels ayant déjà développé sur WinDev et/ou utilisé des applications issues de WinDev, et cela en relation avec une base de données Oracle.

Qu'avez vous pensé de WinDev d'une façon générale ?
Y'avait-il des problèmes majeurs avec la base de données ?
Recommanderiez-vous WinDev et pour quelle raison ?

Je ne demande pas un rapport complet, juste votre avis ainsi que quelques pistes afin de prendre une bonne décision.

Merci d'avance.

[mail.spam]

Bonjour,

Pour les questions suivantes :

Qu'avez vous pensé de WinDev d'une façon générale ?
Recommanderiez-vous WinDev et pour quelle raison ?

Je te conseille de jeter un oeil sur le post suivant Windev ou non

Tu trouvera plein d'avis pour et contre.

Ensuite il ne faut pas oublié que Windev est un environnement de développement, même s'il est mis en avant qu'on peut le prendre en main facilement il faut quand même savoir développer.

Sur le point de vue Oracle je ne ferai aucun commentaire car je ne l'ai jamais utiliser.

Voilà bonne lecture

[klbsjpolp]

Bonjour,

Pour la question de savoir si on vous suggère Windev comme outil, je vous suggère de lire la très exhaustive discussion Windev ou non?.

[raf1987]

Merci beaucoup, je vais lire le sujet de ce pas.

[vmolines]

Pour la partie Oracle avec Windev, je dirais qu'il est partiellement adapté.

La couche d'accès aux données de base ne permet pas de gérer un identifiant automatique par table. Pour être plus précis, une seule séquence est utilisée par Windev pour toutes les tables et il n'est pas possible d'utiliser des séquences spécifiques.

Ca pourra sembler un détail pour certains mais si vous avez un DBA Oracle qui souhaite (à juste titre) avoir une séquence par table, la couche d'accès aux données Windev ne le gère pas et impose son organisation.


Evidemment il est possible d'attaquer les bases en SQL (ce que je conseille) et là tout est permis.

[=JBO=]

Bonjour,

Tu peux aussi lire cette discussion: [WD14] question dev windev/oracle


Je ne pratique pas Oracle, mais je suis assez surpris par la limitation rapportée par vmolines.

La couche d'accès aux données de base ne permet pas de gérer un identifiant automatique par table. Pour être plus précis, une seule séquence est utilisée par Windev pour toutes les tables et il n'est pas possible d'utiliser des séquences spécifiques.

Ca pourra sembler un détail pour certains mais si vous avez un DBA Oracle qui souhaite (à juste titre) avoir une séquence par table, la couche d'accès aux données Windev ne le gère pas et impose son organisation.

Ce que j'ai compris à la lecture de l'aide en ligne, c'est qu'il s'agit d'une situation où la structure d'une base de données Oracle est importée dans une analyse, et qu'on souhaite gérer des Identifiants Automatiques "à la sauce moteur HyperFile".

Accès Natif Oracle : Programmation à l'aide des fonctions HyperFileSQL

Remarque : Gestion de l'identifiant automatique

Le type Identifiant automatique n'existant pas sur Oracle, l'importation d'une table Oracle ne crée pas de rubriques de ce type.

Cependant, il est possible sous l'éditeur d'analyses, de modifier les rubriques de type "Entier sur 4 " et / ou "Entier sur 8" pour les définir comme identifiant automatique. Dans ce cas, ces identifiants automatiques seront gérés par l'Accès Natif Oracle (en ajout ou en modification) grâce à une "Séquence" Oracle nommée "WINDEV_SEQ". Si cette séquence n'existe pas, l'Accès Natif Oracle crée cette séquence automatiquement.

Pour faire des ajouts ou des modifications d'enregistrements avec identifiant automatique, il est nécessaire :

• de modifier l'analyse. En effet, pour une rubrique "Entier sur 4 " ou "Entier sur 8", cette rubrique peut être passée en type "Identifiant auto". Dans ce cas, l'Accès natif Oracle gèrera cette rubrique comme un identifiant automatique.
• soit de créer l'objet "séquence" nommé "WINDEV_SEQ" dans la base Oracle
• soit de donner le privilège "CREATE SEQUENCE" à l'utilisateur.

Mais si on ne veut pas utiliser un Identifiant Automatique "à la HyperFile", et laisser faire Oracle...

Que se passera-t-il lors d'un HAjoute(), ou lors d'un INSERT via HExécuteRequête() ou HExécuteRequêteSQL(), y compris avec l'option hRequêteSansCorrection ???

Les séquences définies dans la BD Oracle ne sont-elles pas "automatiquement" utilisées ?... à l'instar de ce que ferait un trigger en insertion de données.
_

[vmolines]

Côté Oracle, aucun problème, le couple trigger/séquence va bien valoriser l'identifiant quel que soit la méthode employée pour créer un enreg.

Par contre après un HAjoute, le "buffer" fichier ne contiendra pas la bonne valeur. En cause, l'accès natif ne va pas relire l'enreg (ou interroger la dernière valeur de séquence). Il ne le fait que si la rubrique est en identifiant auto dans l'analyse (mais de paire avec le fameux WINDEV_SEQ).

[=JBO=]

Effectivement vmolines,

je viens de voir ça à cette page de l'aide en ligne: Accès Natif Oracle : Limitations et remarques

Notamment le paragraphe suivant qui apporte une préconisation:

Limitations sur les fonctions HyperFileSQL et SQL

Après la fonction HAjoute, l'enregistrement n'est pas relu par l'Accès Natif. Si les valeurs de l'enregistrement sont modifiées par la base de données (trigger sur Insert, ...), il est nécessaire d'utiliser la fonction HLit pour récupérer les valeurs modifiées.

Dans une telle situation, ce serait bien que, dans le futur, le moteur de bases de données HyperFile puisse distinguer 2 types d'identifiants automatiques:
_ • un identifiant automatique "à la HyperFile" (c-à-d fixé par la séquence "WINDEV_SEQ"),
_ • un identifiant automatique natif (c-à-d contrôlé par Oracle et relu "automatiquement" par HyperFile).
_

[vmolines]

Tout à fait, et c'est bien parce qu'il est impossible d'avoir une rubrique identifiant automatique dans l'analyse que je considère que celle-ci n'est pas bien exploitable avec Oracle.

Le contournement fonctionne mais quid d'une application multi base pour laquelle l'identifiant automatique dans l'analyse fonctionne (MySQL notamment) ? On abandonne finalement l'identifiant et on gère à la main.

Ce que je déplore c'est la mise en avant d'une couche d'accès multi base alors qu'il faudra trouver des contournements qui ne permettent finalement pas d'utiliser les mécanismes proposés.

Concernant les problèmes Oracle, j'ajouterai le dernier que j'ai rencontré : impossibilité d'utiliser COALESCE avec une valeur numérique en dur. L'instruction SQL générée par Windev transforme le numérique en chaine sans raison :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

... COALESCE(MaRubrique, 0)...

devient

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

... COALESCE(MaRubrique, '0')...

ce qui provoque une erreur oracle lorsqu'une valeur numérique est attendue.

Je précise que COALESCE n'est pas noté incompatible avec Oracle dans l'aide. C'est juste que le traitement des requêtes est buggé à ce niveau.

[vmolines]

Effectivement vmolines,

je viens de voir ça à cette page de l'aide en ligne: Accès Natif Oracle : Limitations et remarques

Notamment le paragraphe suivant qui apporte une préconisation:



Dans une telle situation, ce serait bien que, dans le futur, le moteur de bases de données HyperFile puisse distinguer 2 types d'identifiants automatiques:
_ • un identifiant automatique "à la HyperFile" (c-à-d fixé par la séquence "WINDEV_SEQ"),
_ • un identifiant automatique natif (c-à-d contrôlé par Oracle et relu "automatiquement" par HyperFile).
_

Mais j'oubliais le plus important par rapport à votre juste réponse . L'aide que vous citez est celle de la V15. Dans ma version 14 30f, cette mention ne figure pas alors que j'ai bien remonté le problème. Une mise à jour de l'aide en V14 aurait été bienvenue, au moins ça ...

[=JBO=]

Tout à fait, et c'est bien parce qu'il est impossible d'avoir une rubrique identifiant automatique dans l'analyse que je considère que celle-ci n'est pas bien exploitable avec Oracle.

Le contournement fonctionne mais quid d'une application multi base pour laquelle l'identifiant automatique dans l'analyse fonctionne (MySQL notamment) ? On abandonne finalement l'identifiant et on gère à la main.

Effectivement, il n'y a pas forcément d'homogénéité entre les différents accès natifs.
Au passage, tu peux remarquer que PC Soft ne revendique pas une gestion uniforme des accès natifs.

Ce que je déplore c'est la mise en avant d'une couche d'accès multi base alors qu'il faudra trouver des contournements qui ne permettent finalement pas d'utiliser les mécanismes proposés.

Mais justement, pour les requêtes nous avons l'option hRequêteSansCorrection qui empêche le moteur HyperFile d'intervenir intempestivement.

Concernant les problèmes Oracle, j'ajouterai le dernier que j'ai rencontré : impossibilité d'utiliser COALESCE avec une valeur numérique en dur. L'instruction SQL générée par Windev transforme le numérique en chaine sans raison :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

... COALESCE(MaRubrique, 0)...

devient

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

... COALESCE(MaRubrique, '0')...

ce qui provoque une erreur oracle lorsqu'une valeur numérique est attendue.

Je précise que COALESCE n'est pas noté incompatible avec Oracle dans l'aide. C'est juste que le traitement des requêtes est buggé à ce niveau.

Là encore, que se passerait-il si on utilise l'option hRequêteSansCorrection pour n'utiliser que la syntaxe et les fonctions SQL natives ?
_

[=JBO=]

Pour rebondir sur cette remarque pertinente

L'aide que vous citez est celle de la V15. Dans ma version 14 30f, cette mention ne figure pas alors que j'ai bien remonté le problème. Une mise à jour de l'aide en V14 aurait été bienvenue, au moins ça ...

Par curiosité et pour comparer les versions, je suis allé lire la même page dans mon WD12 et... (roulement de tambour)... Ô surprise...

La limitation suivante en WD12 est toujours vraie en WD15... _ ce qui me laisse songeur...

Après une erreur de doublons sur la fonction HModifie, la fonction HLit (utilisée avec la constante hNumEnrEnCours) ne lit pas l'enregistrement demandé.

Ce problème sera corrigé dans une prochaine version.

Une « prochaine version » ...
_

[vmolines]

Effectivement, il n'y a pas forcément d'homogénéité entre les différents accès natifs.

Hélas c'est la dessus que doit reposer une couche d'accès multi base efficace.

Au passage, tu peux remarquer que PC Soft ne revendique pas une gestion uniforme des accès natifs.

Je cite http://www.pcsoft-windev-webdev.com/brochureWD15.pdf, page 13 :

WINDEV 15 supporte toutes les bases de données du marché, avec une programmation identique.

Accès natif ou pas, PCSoft met en avant le côté multi bases et précisément le fait que le développeur n'a pas à gérer de particularité.

C'est bien la couche d'accès aux données (Analyse + ordres H*) que ma critique vise.

Mais justement, pour les requêtes nous avons l'option hRequêteSansCorrection qui empêche le moteur HyperFile d'intervenir intempestivement.




Là encore, que se passerait-il si on utilise l'option hRequêteSansCorrection pour n'utiliser que la syntaxe et les fonctions SQL natives ?
_

Bien sûr quand on ne laisse pas la main à Windev sur le SQL il ne risque pas de mal faire.

C'était d'ailleurs la réponse du ST à tous mes problèmes d'accès aux données .

Et pour info, c'est juste parce qu'on me force actuellement à utiliser l'analyse et les ordres H que je les utilise.

[=JBO=]

vmolines, après tout ce que tu viens de nous expliquer j'en conclus qu'une application WinDev développée avec une certaine base de données n'est pas portable en l'état vers n'importe quel autre SGBD pris en charge par le moteur HyperFile.

Donc, il est important de savoir qu'une phase de "portage" est nécessaire.
Ou bien, ne pas compter sur le seul WinDev pour un tel objectif.

Maintenant, pour une société qui n'a pas de visée multi-SGBD, et qui ne veut viser que le SGBD Oracle (par exemple), c'est plutôt pas mal d'avoir l'accès natif, la possibilité de voir la base de données dans l'analyse et de programmer directement avec les "variables de fichier".
_

[vmolines]

...
Maintenant, pour une société qui n'a pas de visée multi-SGBD, et qui ne veut viser que le SGBD Oracle (par exemple), c'est plutôt pas mal d'avoir l'accès natif, la possibilité de voir la base de données dans l'analyse et de programmer directement avec les "variables de fichier".
_

Pour parler de l'analyse, je peux dire qu'il est impossible d'avoir une clé étrangère sur une clé primaire composée et ce depuis très longtemps.

Alors on va me dire "Ca fonctionne si on fait ça comme ça". Je suis désolé mais n'importe quel outil de modélisation ou base de données permet (encore heureux) d'avoir cette configuration. La raison à cela est que l'analyse ne se sort pas du vieil héritage des clés à la sauce Hyperfile.

Juste pour rire, essayez une synchro de l'analyse dans ce cas


Autre chose : générer un script SQL à partir de l'analyse ne fonctionne pas quand on a des rubriques décimales (numérique Windev), le script affiché est vide (bug remonté).


Des points (qui peuvent paraitre du détail pour certains) me font dire que l'analyse et les ordres H* fonctionnent mais faut vraiment pas être exigeant...

Et pour ce qui est d'avoir accès au nom des fichiers directement dans le code, ok c'est mignon mais ça n'apporte pas grand chose. Bien au contraire, le fait de ramener systématiquement toutes les colonnes d'une table est contre performant. Quand on a besoin de X colonnes, on ramène X colonnes.

Ce qui me parleront des impacts lors de la modification, je répondrai CTRL F.

Il faudrait que je ponde un argumentaire structuré contre l'utilisation de l'analyse et des ordres H* car ça m'économiserait du temps lors de mes futurs débats avec des collègues.

[=JBO=]

Pour ma part, je n'envisage pas d'utiliser une analyse WinDev pour concevoir et créer une BD dans un SGBD externe (via un script SQL).
C'est peut être une fonctionnalité de l'éditeur d'analyse, mais... ça me dérange.
En outre, ton expérience montre que ce n'est pas toujours concluant.

Je préfère plutôt la démarche d'importer dans une analyse la structure d'une BD externe.
Et si la structure de la BD externe évolue, on synchronise l'analyse.
Ce qui revient à n'utiliser WinDev "que" pour développer l'application, mais en collant de près à la BD externe, grâce à l'analyse.
J'imagine qu'en travaillant ainsi on à moins de problème sur les clés composées, non ?

Avec une BD externe, se pose la question des triggers ?
_ • Faut-il utiliser les "triggers applicatifs" WinDev/HyperFile ? je ne crois pas...
_ • Faut-il se limiter aux seuls triggers de la BD externe ?

Quant au type de données numérique décimal, quel que soit l'environnement, j'ai toujours vu des problèmes lorsqu'on s'interface avec une BD Oracle.

En fait, il faut faire bien attention à travailler à partir d'un sous-ensemble de types de données commun à l'environnement de développement et au SGBD cible (seulement les types ANSI ou ISO, donc pas de rubriques tableau à la HyperFile; pas de types utilisateurs d'Oracle, etc.).

C'est frustrant de devoir se restreindre à un sous-ensemble des capacités du SGBD.
_

[Emmanuel Lecoester]

Pour WinDev, voir le post adéquat comme proposé

Pour Oracle, est-ce une base "imposée" ? si oui au vu de ce que j'ai lu ici pas de grand problème.

Pour la séquence unique cela ne me choque pas outre mesure (c'est le cas dans bien des cas). Votre DBA ajoutera simplement un "cache 50" pour éviter de ne trop taper sur la séquence.

Si vous souhaitez gérer une séquence par table, à l'issue d'un hajoute il faudra simplement faire "select masequence.currentval from dual" pour récupérer votre identifiant.

De vous à moi, si vous passez sur une base autre que HF passez en mode requete (mode SQL). Un SGBDR est fait pour travailler en ensemble pas par ligne. C'est vrai que c'est plus simple d'écrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
MonFichier.col1= valeur
MonFichier.col2 = valeur2
HAjoute (MonFichier)

que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

insert into (col1, col2) values (valeur, valeur2) ;

Mais la seconde écriture sera compréhensible par tous et surtout pas votre DBA

[Emmanuel Lecoester]

Pour ma part, je n'envisage pas d'utiliser une analyse WinDev pour concevoir et créer une BD dans un SGBD externe (via un script SQL).
C'est peut être une fonctionnalité de l'éditeur d'analyse, mais... ça me dérange.
En outre, ton expérience montre que ce n'est pas toujours concluant.

Je préfère plutôt la démarche d'importer dans une analyse la structure d'une BD externe.
Et si la structure de la BD externe évolue, on synchronise l'analyse.
Ce qui revient à n'utiliser WinDev "que" pour développer l'application, mais en collant de près à la BD externe, grâce à l'analyse.
J'imagine qu'en travaillant ainsi on à moins de problème sur les clés composées, non ?

Avec une BD externe, se pose la question des triggers ?
_ • Faut-il utiliser les "triggers applicatifs" WinDev/HyperFile ? je ne crois pas...
_ • Faut-il se limiter aux seuls triggers de la BD externe ?

Quant au type de données numérique, quel que soit l'environnement, j'ai toujours vu des problèmes lorsqu'on s'interface avec une BD Oracle.

En fait, il faut faire bien attention à travailler à partir d'un sous-ensemble de types de données commun à l'environnement de développement et au SGBD cible (seulement les types ANSI ou ISO, donc pas de rubriques tableau à la HyperFile; pas de types utilisateurs d'Oracle, etc.).

C'est frustrant de devoir se restreindre à un sous-ensemble des capacités du SGBD.
_

Alors là je vais sortir mes griffes Oracle et oui Oracle c'est ma base de travail

Pour la partie analyse, si on utilise une base autre que HF je suis plus pour ne pas utiliser une analyse dans son projet. Inconvénient pour perd TOUS les avantages de l'analyse (et ils sont nombreux)

De prime abord, je suis contre l'utilisation des triggers. Ensuite si tu veux du multi base là tu perds beaucoup et ceci dû à la gestion disparate de ces composants (éléments basés, spécialités du SGBD comme noté : all_users, tableau HF).

Les types numériques se marient très bien avec Oracle... Du moment qu'on fait les bonnes associations !

Conclusion : Oracle + WinDev est fait un très bon couple

[vmolines]

...
Je préfère plutôt la démarche d'importer dans une analyse la structure d'une BD externe.
Et si la structure de la BD externe évolue, on synchronise l'analyse.
Ce qui revient à n'utiliser WinDev "que" pour développer l'application, mais en collant de près à la BD externe, grâce à l'analyse.
J'imagine qu'en travaillant ainsi on à moins de problème sur les clés composées, non ?

Il faudrait que je refasse le test mais je ne pense pas que ça ait évolué depuis mon dernier test.

Avec une BD externe, se pose la question des triggers ?
_ • Faut-il utiliser les "triggers applicatifs" WinDev/HyperFile ? je ne crois pas...
_ • Faut-il se limiter aux seuls triggers de la BD externe ?

JAMAIS DE TRIGGER APPLICATIF. Et en disant je suis déjà à brûler au bûcher car le trigger applicatif n'existe pas. Je m'explique, un trigger est, par définition, interne à la base de données et non applicatif. Si un trigger doit exister, c'est pour faire un traitement obligatoire lorsqu'une opération l'a déclenché. Si je conçois une base de données, je garantis son intégrité et ce quels que soient les ordres qu'elle reçoit. FK, contraintes d'unicité, checks, not null, triggers, ... tout doit être mis en oeuvre pour ne pas permettre d'avoir des données non maitrisées selon les objectifs initialement fixés et peu importe le moyen utilisé pour attaquer la base. Il y en a marre des éternels :

- Non mais on le gère côté application pas besoin
- Il n'y aura jamais ça dans la base de données
- Les triggers c'est compliqué
- Les triggers c'est pas géré par toutes les bases

Le fait de le gérer côté application indique qu'on repousse le problème de la qualité des données à plus tard alors qu'on peut se la poser directement. De plus on peut court circuiter le mécanisme si on utilise pas l'application prévue initialement pour la BDD. Et enfin, on s'expose à un oubli si l'application manipule une même donnée de manière non centralisée.

Les triggers c'est comme tout, c'est compliqué quand on ne sait pas et ça s'apprend. Si on n'a pas le temps ou qu'on ne veut pas, on le fait faire par quelqu'un qui maîtrise le sujet.

Ne pas vouloir utiliser les outils les plus efficaces mis à disposition pour répondre à un problème est du déni. Les triggers sont plus efficaces dans la mesure où ils évitent les aller-retours client serveur pour passer X instructions qui doivent en suivre une initiale. Ils sont sécurisés car ils sont par nature dans la transaction qui a provoqué leur déclenchement. Ils sont plus faciles à mettre en oeuvre car ils sont au plus près des données qu'on manipule.

Les triggers sont gérés par toutes les vraies bases de données (Oracle, SQL Server, MySQL, PostgreSQL, Interbase, ...)[/QUOTE]

C'est frustrant de devoir se restreindre à un sous-ensemble des capacités du SGBD.
_

Oui et il ne faut pas. Il faut choisir sa base de données pour les qualités et les besoins recherchés et s'y tenir. Le multi base tout prêt est une utopie ou un gage de non qualité/non performance ou de surcoût énorme.

[raf1987]

Tout d'abord, merci à tous pour vos nombreuses réponses.

J'ai entendu dire qu'il y avait un problème récurrent avec Windev : il faudrait remodifier le code des applications à chaque changement de version.

Qu'en pensez-vous ?

Le problème se pose-t-il avec d'autres environnements de développement ?

J'aimerais également savoir si la génération de rapport sous Windev était simple et efficace.

Merci d'avance.