|
| Débuté par guest, 08 déc. 2005 10:21 - 6 réponses |
| |
| | | |
|
| |
Posté le 08 décembre 2005 - 10:21 |
Bonjour,
Dans un stade avancé de mon application Windev, je me pose aujourd'hui des questions existentielles.
J'ai appris Windev sans formation et donc peut être ai-je mal compris certaines choses.
Au début, j'utilisais le requeteur mais très vite, j'ai trouvé qu'il ne répondait plus à mes besoins en terme de requetes.
J'ai alors choisi de faire des HExécuteRequêteSQL en construisant moi meme la commande SQL.
Mais je fais face maintenant à des limitations d'ordre SQL.
Exemple : pas de DECODE (oracle) en Hyperfile, pas plus de réussite de l'utilisation du CASE dans un Where, problème dans certaines imbrications de SELECT.
Un exemple concret de commande SQL qui ne passe pas, c'est :
select Xref.MES_No_Message, Xref.XRF_WHAT_ZONE WHAT_ZONE, xref.XRF_WHAT_COORDS WHAT_COORDS, Xref.XRF_Sous_ZONE, xref.XRF_Sous_COORDS, Libellés.LIB_LIBELLé,Zones.ZON_Parente_nonvide
from Xref, Libellés , Zones
where xref.XRF_Id_APPLICATION and Xref.MES_No_Message='1025'
and Libellés.APP_Id=xref.XRF_Id_APPLICATION and Zones.ZON_Code_Zone=xref.XRF_ZONE and Libellés.LIB_CodeZONE= Zones.ZON_Parente_nonvide and Libellés.LIB_CodeSousZone=Xref.XRF_WHAT_ZONE and LIB_COORDonneeS=xref.XRF_WHAT_COORDS
Il bute sur : Zones.ZON_Code_Zone=xref.XRF_ZONE and Libellés.LIB_CodeZONE= Zones.ZON_Parente_nonvide Si j'enlève une des 2 conditions, ca passe mais les 2 en meme temps, il aime pas.
Donc, hier soir, panique !
je me dis de suite que la solution ets de changer de base de donnée, je parcours les forums et évidemment je pense à MYSQL mais j'ai l'impression que ce dernier ne semble pas beaucoup plus performant.
D'autres parlent de FireBird en bien mais quel est celui qui me conviendrait le mieux sachant qu'au début, ce sera une application monoposte en local puis peut être plus tard une application client serveur ?
je recherche un déploiement simple de la base utilisée.
Puis toujours en parcourant le forum, j'apprends (c'est la ou une formation, ca sert) que l'on peut utiliser dans le requeteur des sous requetes.
Estc e que ma commande citée plus haut est interprétable dans le requeteur en le découpant en sous requetes ? Il faut savoir que cette commande est en fait plus importante, voici l'originale en Oracle:
select XRF_MSG msg, XRF_WHAT_ZONE where_zone, XRF_WHAT_COORDS where_coords, XRF_SUB_ZONE param_zone, XRF_SUB_COORDS param_coords, LBL_LIBELLE param
from XREF.XRF, XREF.LBL
where XRF_APPLICATION=pAPPLICATION
and XRF_MSG='1025'
and LBL_APPLICATION=XRF_APPLICATION and LBL_ZONE=decode (XRF_WHAT_ZONE, 'RFL', 'DBF', XRF_ZONE)
and LBL_SUB_ZONE=XRF_WHAT_ZONE and LBL_COORDS=XRF_WHAT_COORDS
union
select XRF_MSG msg, XRF_WHAT_ZONE where_zone, XRF_WHAT_COORDS where_coords, XRF_SUB_ZONE param_zone, XRF_SUB_COORDS param_coords, LBL_LIBELLE param
from XREF.XRF, XREF.LBL
where XRF_APPLICATION=pAPPLICATION
and XRF_MSG='1041'
and LBL_APPLICATION=XRF_APPLICATION and LBL_ZONE=XRF_ZONE
and LBL_SUB_ZONE=XRF_WHAT_ZONE and LBL_COORDS=XRF_WHAT_COORDS
union
select XRF_MSG msg, ' ' where_zone, ' ' where_coords, XRF_SUB_ZONE param_zone, XRF_SUB_COORDS param_coords, XRF_WHAT_COORDS param
from XREF.XRF
where XRF_APPLICATION=pAPPLICATION
and XRF_MSG='1598'
Voilà, j'attends avec impatience vos commentaires et peut être vos encouragements car je trouve que Windev est un joli produit mais que la partie base de donnée reste trop simpliste. Dans la v10, il ne semble pas avoir amélioré la partie SQL ce qui est dommage.
Zag |
| |
| |
| | | |
|
| | |
| |
Posté le 08 décembre 2005 - 11:14 |
Il faut savoir que dans tous les cas les hordres h* permettent de répondre à TOUT type d'accès aux données
On peut TOUT faire avec les ordres *
Donc s'il manque un truc en SQL voir du côté des ordres h* !
Ainsi on n'ets jamais bloqué
Et penser à envoyer les demandes d'évolution à Pc soft, sinon ça n'avancera pas !!! |
| |
| |
| | | |
|
| | |
| |
Posté le 08 décembre 2005 - 11:53 |
Ca ne me rassure pas vraiment mais je garde cette option en issue de secours
La, je me bats avec le requeteur mais déjà, basiquement, je relie 2 tables entre elles.
je crée 2 liaisons manuellement avec la requete et je relie Champ1 Fichier 1 avec Champ1 Fichier 2 et Champ2 Fichier 1 avec Champ2 Fichier 2
Et il me repond : "Il existe plusieurs chemins différents pour relier les fichiers 1 et 2....
et il me demande de choisir entre l'une et l'autre mais moi j'ai besoin des 2 liaisons.
Y a t'il une astuce ?
Zag |
| |
| |
| | | |
|
| | |
| |
Posté le 08 décembre 2005 - 14:02 |
Votre requete HF diffère de celle de Oracle (une table en plus dans HF).
Votre requete Oracle composée de 3 requetes en union peut donc être découpée en 3 requetes executer l'une à la suite de l'autre.
Maintenant sur votre besoin : Je ne connais aucune migration où tout se passe nickel ! Comme vous le soulignez certaines commandes SQL ne sont pas compatibles entre bases de données (le decode, (+) de Oracle...). Donc il m'apparait normal de retoucher le code SQL.
Maintenant vous souhaitez une base en local : HF correspond parfaitement à votre besoin. Il ne faut pas s'arreter à ces poblèmes de migration de requetes ^^. Vu que vous avez des connaissances Oracle pourquoi ne pas utiliser Oracle XE qui est limité mais en poste local devrait vous suffir.
PS : pour info un union all est plus rapide qu'un union qui tente de dédoublonner les enregistrements lus. Donc si vos 3 requetes sont complémentaires et non supplémentaires, vous pouvez gagner un peu de temps.
--
Emmanuel Lecoester |
| |
| |
| | | |
|
| | |
| |
Posté le 08 décembre 2005 - 14:39 |
Merci Emmanuel,
J'ai eu l'occasion de tomber sur plusieurs de vos réponses et elles sont souvent très intéressantes.
Effectivement, la solution pour moi a été de découper ma requête en 4 requêtes.
4 car l'une d'elle utilisant un decode a été scindée en 2.
Oui, HF, semble convenir si je ne le provoque pas de trop.
Pour Oracle XE, çà me parait extremement tentant et semble parfait pour mon application.
Merci beaucoup
A bientôt
Zag |
| |
| |
| | | |
|
| | |
| |
Posté le 08 décembre 2005 - 17:46 |
Je ne vois pas le problème
il faut savoir que historiquement, Hyper File n'existait qu'avec les ordres 'h'.
Ces ordres sont bien plus puissants que SQL à mon avis, on peut programmer absolument tout ce que l'on veut avec ! Le problème est qu'en réseau ou en client/serveur ça génère du traffic pas forcement bienvenue...
Ensuite SQL a été ajouté à Hyper File
Y'a pas tout encore, mais je ne voispas ce que ça a de pas rassurant !
Je crois qu'il ne faut pas être un 'extrémiste' et ne vouloir tout faire systématiquement qu'en SQL !!! Ca c'est mon avis... Windev apporte des tonnes de solutions, il ne faut pas rester borné sur un sujet... |
| |
| |
| | | |
|
| | |
| |
Posté le 08 décembre 2005 - 20:19 |
"Phil" <philippe.noireau@prive.com> writes:
Je ne vois pas le problème il faut savoir que historiquement, Hyper
File n'existait qu'avec les ordres 'h'. Ces ordres sont bien plus
puissants que SQL à mon avis, on peut programmer absolument tout ce
que l'on veut avec !
regarder les fonctions qui existe en SQL sur d'autres bases avant
d'écrire.
Regarder pour les chaines ce qu'on peut faire directement sur un
serveur en SQL
http://traduc.postgresqlfr.org/pgsql-fr/functions-string.html
idem pour les dates :
http://www.toutestfacile.com/sql/cours/printables/SQLFacile.com-functdate.php
Le problème est qu'en réseau ou en client/serveur
ça génère du traffic pas forcement bienvenue... Ensuite SQL a été
ajouté à Hyper File Y'a pas tout encore, mais je ne voispas ce que ça
a de pas rassurant ! Je crois qu'il ne faut pas être un 'extrémiste'
et ne vouloir tout faire systématiquement qu'en SQL !!! Ca c'est mon
avis... Windev apporte des tonnes de solutions, il ne faut pas rester
borné sur un sujet...
Vous avez déjà fait du SQL pour écrire ce type de contre-vérité.
Les commandes Hfiltre etc ... sont très pratiques lorsqu'on ne fait pas
de jointure, elles sont optimisées pour HF etc... Mais il sera plus
efficace de passer sur du SQL dès qu'on veut des résultats sur
plusieurs tables reliées par des FK.
Votre réponse me fait penser à un directeur de développement qui m'avait dit
: "le SQL c'est puissant, mais c'est moins lisible".
Sur une base respectant SQL2, il a donc tout fait en H*, celà lui a pris 2
heures de boulot, de mon coté j'ai tout fait en SQL (8 heures de
boulot, je ne suis pas très doué). Il était fier le directeur du
développement avec sa moulinette faite en 2 heures!
On passe sur une base de production, on lance en même temps notre
application....
Sur une base test d'un trimestre son appli après 24 heures, n'avait
pas terminé (après on ne sait pas car le poste à planté par manque de
ressources  )
Au bout de 20 minutes tout était fini avec l'appli en SQL
Ce n'est pas parceque Windev est un outil facile et agréable à
utiliser qu'il faut lui faire avaler n'importe quoi
Exemple tout simple : vous faites une appli en HF classique, il y a
intéret à privilégier des tables avec de nombreuses rubriques, et a
utiliser les Hcréevue, pour au contraire, passer sur des tables moins
"larges" et reliées avec des FK sur un SGBDR type HF C/S.
Ensuite le mode d'interrogation va être à adapter. Si c'est pour faire
un écran-fiche les méthodes H* sont adaptées. Car simple à écrire et à
relire...
Si vous faites la même chose pour des tables reliées vous générez du
traffic et du calcul par le client, ce sera beaucoup plus efficace si
c'est le serveur qui le fait en passant par le SQL.
C'est pour dire que Windev ne fait pas tout, et même si c'est un bon
outil, il est nécessaire dans connaître les limites.
Zag avait un souci, Lecoester a apporté une solution.
--
suivre ce lien pour répondre:
http://cerbermail.com/…
Daniel
|
| |
| |
| | | |
|
| | | | |
| | |
|