|
| Surcharger HexécuteRequête |
| Débuté par Yvan, 24 juin 2019 15:56 - 10 réponses |
| |
| | | |
|
| |
Membre enregistré
202 messages
Popularité : +6 (6 votes) |
|
Posté le 24 juin 2019 - 15:56 |
Bonjour,
Je souhaite surcharger la procédure Windev HexécuteRequête comme je l'ai déjà fait avec succès pour HexécuteRequèteSQL.
Voici le code de la procédure surchargée :
Procedure HExécuteRequête(sRequete,*):booléen
SI gclConnexion:m_sTypeBase = hOledbSQLServer ALORS
RENVOYER WL.HExécuteRequête(sRequete,gclConnexion.m_sNomCnx,hRequêteSansCorrection,MesParamètres[2 À ])
SINON SI gclConnexion:m_bModeClientServeur
RENVOYER WL.HExécuteRequête(sRequete,gclConnexion.m_sNomCnx,hRequêteDéfaut,MesParamètres[2 À ])
SINON
RENVOYER WL.HExécuteRequête(sRequete,hRequêteDéfaut,MesParamètres[2 À ])
FIN
Mais j'obtiens le message d'erreur suivant :
Erreur à la ligne 10 du traitement Procédure globale HExécuteRequête.
Aucune syntaxe de 'HExécuteRequête' ne correspond à l'appel.
J'imagine que c'est parce que la requête passée en paramètre est une chaine alors qu'elle doit être une "requête" au sens Windev du terme.
J'ai essayé de traiter la requête en indirection mais là le message d'erreur est :
Erreur à la ligne 10 du traitement Procédure globale HExécuteRequête.
Le fichier, la vue ou la requête 'Select_Parametres' n'est pas connu.
Un conseil?
Merci. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
3 889 messages
Popularité : +227 (347 votes) |
|
Posté le 24 juin 2019 - 16:27 |
Yvan a écrit :
J'imagine que c'est parce que la requête passée en paramètre est une chaîne alors qu'elle doit être une "requête" au sens Windev du terme.
C'est en effet cela. Éventuellement, cela peut être une variable de type Requête SQL ou le nom d'une requête créée sous l'éditeur
--
Il y a peut être plus simple, mais, ça tourneMessage modifié, 24 juin 2019 - 16:28 |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
202 messages
Popularité : +6 (6 votes) |
|
Posté le 24 juin 2019 - 20:36 |
OK, mais même en constatant ça, Windev n'interprète pas le paramètre comme tel, même en essayant une indirection (pas vraiment prévue pour les requêtes de l'éditeur). |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
1 623 messages
Popularité : +100 (114 votes) |
|
Posté le 25 juin 2019 - 10:28 |
Hello,
Peux nous montrer le code qui fait appel a cette procédure ? |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
202 messages
Popularité : +6 (6 votes) |
|
Posté le 25 juin 2019 - 11:59 |
Bonjour,
En fait j'aimerai surcharger tous mes appels à HexécuteRequête, et donc ne lui passer plus que la requête et ses paramètres:
SI HExécuteRequête(Select_couleurEntrepotUnique,Table_Articles.COL_VOCARTIDA[i] ) ALORS
Dans le code ci-dessus, Select_couleurEntrepotUnique est une requête construite sous l'éditeur qui attend 1 paramètre. Dans de rares cas ce sera une variable de type requete SQL, mais si nécessaire je les traiterais autrement.
Juste pour info, l'application concernée peut fonctionner sur une DB HFSQL classique, ou HFSQL CS ou MSSQL, ce qui explique mes 3 syntaxes du hexécuteRequête.
Yvan |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
1 623 messages
Popularité : +100 (114 votes) |
|
Posté le 25 juin 2019 - 12:32 |
Et quand tu execute le code avec
SI HExécuteRequête(Select_couleurEntrepotUnique,Table_Articles.COL_VOCARTIDA[i] ) ALORS
Tu a l'erreur ? .. c'est curieux, si Select_couleurEntrepotUnique est une requete en provenance de l'editeur ca devrait fonctionner ... :s |
| |
| |
| | | |
|
| | |
| |
Posté le 25 juin 2019 - 14:56 |
Oui, l'erreur est celle reprise plus haut (requête différente mais le problème est identique pour toutes) :
Yvan a écrit :
Mais j'obtiens le message d'erreur suivant :
Erreur à la ligne 10 du traitement Procédure globale HExécuteRequête.
Aucune syntaxe de 'HExécuteRequête' ne correspond à l'appel.
J'ai essayé de traiter la requête en indirection mais là le message d'erreur est :
Erreur à la ligne 10 du traitement Procédure globale HExécuteRequête.
Le fichier, la vue ou la requête 'Select_Parametres' n'est pas connu.
|
| |
| |
| | | |
|
| | |
| |
Posté le 25 juin 2019 - 15:37 |
Bonjour,
En utilisant une variable source de données, ça semble fonctionner.
Procedure HExécuteRequête(sRequete est une Source dede Données,*):booléen
LOCAL
bRet est un booléen
bRet = WL.HExécuteRequête(sRequete,hRequêteDéfaut)
SI PAS bRet ALORS
Erreur(ErreurInfo())
SINON
Info("Je m'épate !")
FIN
RENVOYER bRet
appel :
rDateArchivage.pNomBase = "blabla"
HExécuteRequête(rDateArchivage, hRequêteDéfaut)
Info(HNbEnr(rDateArchivage))
SI HLitPremier(rDateArchivage) ALORS Info(rDateArchivage.DateArchivage)
Je ne passe jamais les paramètres directement via HExecuteRequete mais j'imagine que ça devrait fonctionner. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
202 messages
Popularité : +6 (6 votes) |
|
Posté le 25 juin 2019 - 19:04 |
Bonjour Erwan,
Excellente idée, ça fonctionne.
Petit bémol, il faut de fait gérer les paramètres différemment, sinon ils sont tous traités comme des chaines et les requêtes ne savent plus retourner un résultat correct, ce qui est logique. De plus, ça me forcera à passer mes paramètres à ces requêtes avant le hexécuteRequête et ainsi d'éviter que l'ordre des paramètres se mélange d'une version windev à l'autre...
Merci à vous tous de m'avoir aidé à écrire correctement cette surcharge bien pratique.
Voici finalement comment j'utilise la surcharge :
Procedure HExécuteRequête(sdReq est une Source dede Données,nMode=-1):booléen
SI nMode = -1 ALORS
SI gclConnexion:m_sTypeBase = hOledbSQLServer ALORS
RENVOYER WL.HExécuteRequête(sdReq,gclConnexion.m_sNomCnx,hRequêteSansCorrection)
SINON SI gclConnexion:m_bModeClientServeur
RENVOYER WL.HExécuteRequête(sdReq,gclConnexion.m_sNomCnx,hRequêteDéfaut)
SINON
RENVOYER WL.HExécuteRequête(sdReq,hRequêteDéfaut)
FIN
SINON
SI gclConnexion:m_sTypeBase = hOledbSQLServer ALORS
RENVOYER WL.HExécuteRequête(sdReq,gclConnexion.m_sNomCnx,nMode)
SINON SI gclConnexion:m_bModeClientServeur
RENVOYER WL.HExécuteRequête(sdReq,gclConnexion.m_sNomCnx,nMode)
SINON
RENVOYER WL.HExécuteRequête(sdReq,nMode)
FIN
FIN
Par défaut je ne passe pas de mode à HExécuteRequête et du coup j'utilise le mode qui m'intéresse selon le type de BDD, et je me garde le droit de le forcer au besoin.
Dans mon code, je repasse sur tous mes HExécuteRequête et j'identifie les paramètres de la requête avant l'appel :
select_DroitsVisuEditSupp.ParamIdUser = :p_nIdUtilisateur
SI HExécuteRequête(select_DroitsVisuEditSupp) ALORS
Bons devs. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
3 889 messages
Popularité : +227 (347 votes) |
|
Posté le 25 juin 2019 - 20:07 |
Pourquoi ne pas utiliser TypeVar
Procedure HExécuteRequête(MaReq,*):booléen
SELON TypeVar(MaReq)
CAS wlSourceDeDonnées :
...
CAS wlChaîne :
...
AUTRE CAS :
--
Il y a peut être plus simple, mais, ça tourne |
| |
| |
| | | |
|
| | |
| |
Posté le 27 juin 2019 - 16:25 |
Rebonjour,
Il y a tout de même un bémol...
Ca fonctionne bien pour les sources de données, c'est à dire les requêtes faites via l'éditeur.
Par contre les requêtes SQL faites via le type de variable requête SQL, ça ne fonctionne pas.
Le message d'erreur est : "l'élement _QUERY_Select_29 n'a pas été trouvé".
J'ai bien tenté de passer par un typevar(), car de fait le type de variable d'une variable requête SQL est wlRequeteSQL et pas wlSourceDeDonnees, mais ça ne m'avance pas de le savoir, car je ne peut typer une variable dans ce type qu'en déclarant sont contenu directement, alors qu'ici je la reçoit en paramètre et je veux juste la transmettre à la fonction Windev mais correctement typée...
Bref, je crois que pour les requêtes SQL faites via le type de variable requête SQL je vais oublier la surcharge ...
Sauf si vous avez une meilleur idée. |
| |
| |
| | | |
|
| | | | |
| | |
|