J'ai un bug assez incroyable: si j'appelle la fonction SQLExec depuis un
etat, celle-ci est rejetee (SQLExec renvoie Faux mais sql.MesErreur ne donne
rien ?!). Ce probleme est aussi vrai avec les appels "derives", par exemple
dans le code de l'etat, si j'appelle une fonction de l'appli qui appelle
SQLExec, j'ai la meme erreur; par exemple:
// Code Avant impression DEBUT_DOCUMENT
gDevise:Init(2,"20040213") // Rejet de la commande SQLExec
...
// Dans l'appli
gDevise::Init(pNumDev,pDate)
lCond est une chaîne
lCond = "select TYPE,DATE,TAUXDEV from TAUXDEV where NUMDEV = " + pNumDev+
" and TYPE = 'C' and DATE <= '" + pDate + "'"
lCond += " order by DATE desc limit 1"
SI SQLExec(lCond,"REQ1") ALORS
// si sqlfetch("REQ1") = 0 alors
// FIN
SINON
Erreur(lCond) // J'ai bien rejet de SQLExec
FIN
SQLFerme("REQ1")
retour
// Par contre, avec ExecuteRequeteSQL(), ca marche !!!!!
gDevise::Init(pNumDev,pDate)
lCond est une chaîne
lCond = "select TYPE,DATE,TAUXDEV from TAUXDEV where NUMDEV = " + pNumDev+
" and TYPE = 'C' and DATE <= '" + pDate + "'"
lCond += " order by DATE desc limit 1"
SI ExecuteRequeteSQL(lReq,lCond) ALORS
Info("ca marche ?????????!!!!!!!!!")
SINON
Erreur(lCond)
FIN
HAnnuleDeclaration(lReq)
retour
Pouvez-vous me confirmer ce bug et si vous connaissez un moyen de le
contourner sans que je transforme tous les SQLExec en HExecuteRequeteSQL
(qui sont d'aillerus moins performants sur MySQL)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
ted
"I.G.LOG" écrivait news:cfqmkj$bhk$:
J'ai un bug assez incroyable: si j'appelle la fonction SQLExec depuis un etat, celle-ci est rejetee (SQLExec renvoie Faux mais sql.MesErreur ne donne rien ?!). Ce probleme est aussi vrai avec les appels "derives", par exemple dans le code de l'etat, si j'appelle une fonction de l'appli qui appelle SQLExec, j'ai la meme erreur; par exemple:
// Code Avant impression DEBUT_DOCUMENT gDevise:Init(2,"20040213") // Rejet de la commande SQLExec ...
// Dans l'appli gDevise::Init(pNumDev,pDate)
lCond est une chaîne
lCond = "select TYPE,DATE,TAUXDEV from TAUXDEV where NUMDEV = " + pNumDev+ " and TYPE = 'C' and DATE <= '" + pDate + "'" lCond += " order by DATE desc limit 1" SI SQLExec(lCond,"REQ1") ALORS // si sqlfetch("REQ1") = 0 alors // FIN SINON Erreur(lCond) // J'ai bien rejet de SQLExec FIN SQLFerme("REQ1")
retour
// Par contre, avec ExecuteRequeteSQL(), ca marche !!!!! gDevise::Init(pNumDev,pDate)
lCond est une chaîne
lCond = "select TYPE,DATE,TAUXDEV from TAUXDEV where NUMDEV = " + pNumDev+ " and TYPE = 'C' and DATE <= '" + pDate + "'" lCond += " order by DATE desc limit 1" SI ExecuteRequeteSQL(lReq,lCond) ALORS Info("ca marche ?????????!!!!!!!!!") SINON Erreur(lCond) FIN HAnnuleDeclaration(lReq)
retour
Pouvez-vous me confirmer ce bug et si vous connaissez un moyen de le contourner sans que je transforme tous les SQLExec en HExecuteRequeteSQL (qui sont d'aillerus moins performants sur MySQL)
Merci a tous Phil
Salut, j'ai eu un pb du genre et le ST pcsoft ma conseillé d'enlever l'option "contexte Hyper File indépendant", même si on est par sur HF. Et en effet sans cette option tout est allé au poil.
J'ai un bug assez incroyable: si j'appelle la fonction SQLExec depuis
un etat, celle-ci est rejetee (SQLExec renvoie Faux mais sql.MesErreur
ne donne rien ?!). Ce probleme est aussi vrai avec les appels
"derives", par exemple dans le code de l'etat, si j'appelle une
fonction de l'appli qui appelle SQLExec, j'ai la meme erreur; par
exemple:
// Code Avant impression DEBUT_DOCUMENT
gDevise:Init(2,"20040213") // Rejet de la commande SQLExec
...
// Dans l'appli
gDevise::Init(pNumDev,pDate)
lCond est une chaîne
lCond = "select TYPE,DATE,TAUXDEV from TAUXDEV where NUMDEV = " +
pNumDev+ " and TYPE = 'C' and DATE <= '" + pDate + "'"
lCond += " order by DATE desc limit 1"
SI SQLExec(lCond,"REQ1") ALORS
// si sqlfetch("REQ1") = 0 alors
// FIN
SINON
Erreur(lCond) // J'ai bien rejet de SQLExec
FIN
SQLFerme("REQ1")
retour
// Par contre, avec ExecuteRequeteSQL(), ca marche !!!!!
gDevise::Init(pNumDev,pDate)
lCond est une chaîne
lCond = "select TYPE,DATE,TAUXDEV from TAUXDEV where NUMDEV = " +
pNumDev+ " and TYPE = 'C' and DATE <= '" + pDate + "'"
lCond += " order by DATE desc limit 1"
SI ExecuteRequeteSQL(lReq,lCond) ALORS
Info("ca marche ?????????!!!!!!!!!")
SINON
Erreur(lCond)
FIN
HAnnuleDeclaration(lReq)
retour
Pouvez-vous me confirmer ce bug et si vous connaissez un moyen de le
contourner sans que je transforme tous les SQLExec en
HExecuteRequeteSQL (qui sont d'aillerus moins performants sur MySQL)
Merci a tous
Phil
Salut,
j'ai eu un pb du genre et le ST pcsoft ma conseillé d'enlever l'option
"contexte Hyper File indépendant", même si on est par sur HF.
Et en effet sans cette option tout est allé au poil.
J'ai un bug assez incroyable: si j'appelle la fonction SQLExec depuis un etat, celle-ci est rejetee (SQLExec renvoie Faux mais sql.MesErreur ne donne rien ?!). Ce probleme est aussi vrai avec les appels "derives", par exemple dans le code de l'etat, si j'appelle une fonction de l'appli qui appelle SQLExec, j'ai la meme erreur; par exemple:
// Code Avant impression DEBUT_DOCUMENT gDevise:Init(2,"20040213") // Rejet de la commande SQLExec ...
// Dans l'appli gDevise::Init(pNumDev,pDate)
lCond est une chaîne
lCond = "select TYPE,DATE,TAUXDEV from TAUXDEV where NUMDEV = " + pNumDev+ " and TYPE = 'C' and DATE <= '" + pDate + "'" lCond += " order by DATE desc limit 1" SI SQLExec(lCond,"REQ1") ALORS // si sqlfetch("REQ1") = 0 alors // FIN SINON Erreur(lCond) // J'ai bien rejet de SQLExec FIN SQLFerme("REQ1")
retour
// Par contre, avec ExecuteRequeteSQL(), ca marche !!!!! gDevise::Init(pNumDev,pDate)
lCond est une chaîne
lCond = "select TYPE,DATE,TAUXDEV from TAUXDEV where NUMDEV = " + pNumDev+ " and TYPE = 'C' and DATE <= '" + pDate + "'" lCond += " order by DATE desc limit 1" SI ExecuteRequeteSQL(lReq,lCond) ALORS Info("ca marche ?????????!!!!!!!!!") SINON Erreur(lCond) FIN HAnnuleDeclaration(lReq)
retour
Pouvez-vous me confirmer ce bug et si vous connaissez un moyen de le contourner sans que je transforme tous les SQLExec en HExecuteRequeteSQL (qui sont d'aillerus moins performants sur MySQL)
Merci a tous Phil
Salut, j'ai eu un pb du genre et le ST pcsoft ma conseillé d'enlever l'option "contexte Hyper File indépendant", même si on est par sur HF. Et en effet sans cette option tout est allé au poil.
-- En esperant t'avoir aidé. ted
I.G.LOG
> Salut, j'ai eu un pb du genre et le ST pcsoft ma conseillé d'enlever l'option "contexte Hyper File indépendant", même si on est par sur HF. Et en effet sans cette option tout est allé au poil.
-- En esperant t'avoir aidé. ted
Bonjour, Sur ton conseil, j'ai decoche "l'execution n'affecte pas les parcours (contexte HyperFile independant) dans le description de l'etat mais le probleme persiste. Nota: suis en version WD8 80.315j
>
Salut,
j'ai eu un pb du genre et le ST pcsoft ma conseillé d'enlever l'option
"contexte Hyper File indépendant", même si on est par sur HF.
Et en effet sans cette option tout est allé au poil.
--
En esperant t'avoir aidé.
ted
Bonjour,
Sur ton conseil, j'ai decoche "l'execution n'affecte pas les parcours
(contexte HyperFile independant) dans le description de l'etat mais le
probleme persiste.
Nota: suis en version WD8 80.315j
> Salut, j'ai eu un pb du genre et le ST pcsoft ma conseillé d'enlever l'option "contexte Hyper File indépendant", même si on est par sur HF. Et en effet sans cette option tout est allé au poil.
-- En esperant t'avoir aidé. ted
Bonjour, Sur ton conseil, j'ai decoche "l'execution n'affecte pas les parcours (contexte HyperFile independant) dans le description de l'etat mais le probleme persiste. Nota: suis en version WD8 80.315j
I.G.LOG
Apres verfication, ca marche en decochant "contexte hyperfile independant". Merci encore
Apres verfication, ca marche en decochant "contexte hyperfile independant".
Merci encore
