HExecuteRequeteSQL et MySQL

I.G.LOG wrote:

2- d'utiliser les fonctions SQL... du W-Langage ?

Je ne comprend pas pour le point 2: j'utilise bien la fonction SQL du
W-Langage HExecuteRequeteSQL() qui plante sur MySQL mais pas sur HyperFile !

F1 sur SQLExec par exemple

SELECT OL.OLCLEUNIK, ARTICLES.ABRCONST, DOSSIER.NUMDOS
FROM OL
LEFT OUTER JOIN ARTICLES ON ARTICLES.ARCLEUNIK = OL.ARCLEUNIK
LEFT OUTER JOIN DOSSIER ON DOSSIER.DSCLEUNIK = OL.DSCLEUNIK
WHERE OL.TERMINE = 0

fonctionne (j'ai enlevé la virgule et ol entre les 2 left outer)

sinon la classe de Eric Roumegou
génère le code suivant pour MySQL

SELECT OL.OLCLEUNIK,ARTICLES.ABRCONST,DOSSIER.NUMDOS FROM OL LEFT OUTER
JOIN DOSSIER ON OL.DSCLEUNIK=DOSSIER.DSCLEUNIK LEFT OUTER JOIN ARTICLES ON
OL.ARCLEUNIK=ARTICLES.ARCLEUNIK WHERE (OL.TERMINE = 0)

et (pour le fun) pour oracle :

SELECT OL.OLCLEUNIK,ARTICLES.ABRCONST,DOSSIER.NUMDOS FROM
OL,ARTICLES,DOSSIER WHERE (OL.TERMINE = 0) AND
((OL.ARCLEUNIK=ARTICLES.ARCLEUNIK(+)) AND OL.DSCLEUNIK=DOSSIER.DSCLEUNIK(+))

à partir du code suivant :

MonSQL:RAZ()
MonSQL:AddSelect("OL","OLCLEUNIK")
MonSQL:AddSelect("ARTICLES","ABRCONST")
MonSQL:AddSelect("Dossier","NUMDOS")
MonSQL:AddJoin("OL.ARCLEUNIK=ARTICLES.ARCLEUNIK", "LEFT")
MonSQL:AddJoin("OL.DSCLEUNIK=DOSSIER.DSCLEUNIK", "LEFT")
MonSQL:AddWhere("OL.TERMINE = 0")

RENVOYER MonSQL:Rtv_ReqSQL()

Remarque: il faut faire attention dans les ordres car avec des left et des
right on se perd rapidement. D'autant plus qu'avec ce type de requete les
performances sont très rarement au RDV.

Pour conclure sur notre cas pratique, je dirais à première vue que c'est le
code SQL de HF qui n'est pas compatible ;-)

"I.G.LOG" <iglog@free.fr> a écrit dans le message de news:
cbudoa$mc$1@news-reader1.wanadoo.fr...

Bonjour,
Tjrs mes pb avec HExecutreRequeteSQL sur MySQL. J'ai une erreur de syntaxe
near 'ARCLEUNIK = OL.ARCLEUNIK, DOSSIER DOSSIER left outer join CL'
sur le code suivant:

select OL.OLCLEUNIK, OL.TYPEPRE, OL.INDICE, OL.DATEDEB, OL.DELAI,
OL.NUMCONTROLE, OL.NUMSOC, OL.SUSPENDU, OL.CLOTURE, OL.PRCLEUNIK,
OL.ARCLEUNIK,
DOSSIER.NUMDOS, DOSSIER.NUMSOC as SocOrigine,
CLIENT.RAISON, CLIENT.CLIENTETAT,
ARTICLES.ABRCONST, ARTICLES.REFCONST, ARTICLES.NUMFAM
from
OL OL left outer join ARTICLES ARTICLES on ARTICLES.ARCLEUNIK > OL.ARCLEUNIK,
DOSSIER DOSSIER left outer join CLIENT CLIENT on CLIENT.CLCLEUNIK > DOSSIER.CLCLEUNIK
where OL.TERMINE = 0
and OL.NUMSOC = 1
and OL.NUMDEP = 1
and DOSSIER.DSCLEUNIK = OL.DSCLEUNIK

cette requete fonctionne sur HF7 mais pas sur MySQL 4.0.20c !
PS: Je suis en train d'essayer de migrer une grosse appli HF7 -> MySQL et
rares sont les requetes compatibles. Je croyais que SQL etait un langage
standardisé !!!!!!!!

Bonjour,
Apres essais, le probleme vient de HExecuteRequeteSQL() ! En effet, avec
SQLExec() je n'ai plus d'erreur MySQL:

lCond = "select OL.OLCLEUNIK, OL.TYPEPRE, OL.INDICE, OL.DATEDEB, OL.DELAI, "
+...
" OL.NUMCONTROLE, OL.NUMSOC, OL.SUSPENDU, OL.CLOTURE, OL.PRCLEUNIK,
OL.ARCLEUNIK," +...
" DOSSIER.NUMDOS, DOSSIER.NUMSOC as SocOrigine," +...
" CLIENT.RAISON, CLIENT.CLIENTETAT," +...
" ARTICLES.ABRCONST, ARTICLES.REFCONST, ARTICLES.NUMFAM" +...
" from" +...
" OL OL left outer join ARTICLES ARTICLES on ARTICLES.ARCLEUNIK OL.ARCLEUNIK," +...
" DOSSIER DOSSIER left outer join CLIENT CLIENT on CLIENT.CLCLEUNIK DOSSIER.CLCLEUNIK" +...
" where OL.TERMINE = 0" +...
" and OL.NUMSOC = " + Projet:Societe:Ident + ...
" and OL.NUMDEP = " + COMBDEP[COMBDEP] +...
" and DOSSIER.DSCLEUNIK = OL.DSCLEUNIK"
SQLExec(lCond,"lReq") // Fonctionne avec HF et MySQL
HExecuteRequeteSQL(lReq,lCond) // Fonctionne avec HF mais pas avec
MySQL !!!

J'ai transmis au ST.

Pour résumer, il faut utiliser SQLExec() et pas HExecuteRequeteSQL(). La
migration HF -> MySQL s'avere de plus en plus difficile ! J'espere que
SQLManagerX va nous "sauver", notamment avec la fonction SQLRecupereExec qui
permet (je crois) de s'affranchir des SQLLitCol() (avec SQLLitCol, si on
change l'ordre des champs dans le select = bonjour les degats !)

Autre probleme inquietant: Christian m'a contacté apres avoir migre sa base
sous MySQL avec SQLConvert. "je ne pas modifier les enregistrements importés
(seulement ceux créés par elle.. Et je n'ai qu'un seul utilisateur pour
Mysql !!)"
Pour ma part, je n'en suis pas encore là (je ne teste que les lectures
actuellement). Mais, avant que je me lance completement, quelqu'un a-t-il
une info sur ce problème ?

Merci à tous

"elecoest" <elecoest@wanadoo.fr> a écrit dans le message de
news:cburku$6co$1@news-reader2.wanadoo.fr...

SELECT OL.OLCLEUNIK, ARTICLES.ABRCONST, DOSSIER.NUMDOS
FROM OL
LEFT OUTER JOIN ARTICLES ON ARTICLES.ARCLEUNIK = OL.ARCLEUNIK
LEFT OUTER JOIN DOSSIER ON DOSSIER.DSCLEUNIK = OL.DSCLEUNIK
WHERE OL.TERMINE = 0

fonctionne (j'ai enlevé la virgule et ol entre les 2 left outer)

sinon la classe de Eric Roumegou
génère le code suivant pour MySQL

SELECT OL.OLCLEUNIK,ARTICLES.ABRCONST,DOSSIER.NUMDOS FROM OL LEFT OUTER
JOIN DOSSIER ON OL.DSCLEUNIK=DOSSIER.DSCLEUNIK LEFT OUTER JOIN ARTICLES ON
OL.ARCLEUNIK=ARTICLES.ARCLEUNIK WHERE (OL.TERMINE = 0)

et (pour le fun) pour oracle :

SELECT OL.OLCLEUNIK,ARTICLES.ABRCONST,DOSSIER.NUMDOS FROM
OL,ARTICLES,DOSSIER WHERE (OL.TERMINE = 0) AND
((OL.ARCLEUNIK=ARTICLES.ARCLEUNIK(+)) AND

OL.DSCLEUNIK=DOSSIER.DSCLEUNIK(+))

à partir du code suivant :

MonSQL:RAZ()
MonSQL:AddSelect("OL","OLCLEUNIK")
MonSQL:AddSelect("ARTICLES","ABRCONST")
MonSQL:AddSelect("Dossier","NUMDOS")
MonSQL:AddJoin("OL.ARCLEUNIK=ARTICLES.ARCLEUNIK", "LEFT")
MonSQL:AddJoin("OL.DSCLEUNIK=DOSSIER.DSCLEUNIK", "LEFT")
MonSQL:AddWhere("OL.TERMINE = 0")

RENVOYER MonSQL:Rtv_ReqSQL()

Remarque: il faut faire attention dans les ordres car avec des left et des
right on se perd rapidement. D'autant plus qu'avec ce type de requete les
performances sont très rarement au RDV.

Pour conclure sur notre cas pratique, je dirais à première vue que c'est

le

code SQL de HF qui n'est pas compatible ;-)

"I.G.LOG" <iglog@free.fr> a écrit dans le message de news:
cbudoa$mc$1@news-reader1.wanadoo.fr...
> Bonjour,
> Tjrs mes pb avec HExecutreRequeteSQL sur MySQL. J'ai une erreur de

syntaxe

> near 'ARCLEUNIK = OL.ARCLEUNIK, DOSSIER DOSSIER left outer join CL'
> sur le code suivant:
>
> select OL.OLCLEUNIK, OL.TYPEPRE, OL.INDICE, OL.DATEDEB, OL.DELAI,
> OL.NUMCONTROLE, OL.NUMSOC, OL.SUSPENDU, OL.CLOTURE, OL.PRCLEUNIK,
> OL.ARCLEUNIK,
> DOSSIER.NUMDOS, DOSSIER.NUMSOC as SocOrigine,
> CLIENT.RAISON, CLIENT.CLIENTETAT,
> ARTICLES.ABRCONST, ARTICLES.REFCONST, ARTICLES.NUMFAM
> from
> OL OL left outer join ARTICLES ARTICLES on ARTICLES.ARCLEUNIK > > OL.ARCLEUNIK,
> DOSSIER DOSSIER left outer join CLIENT CLIENT on CLIENT.CLCLEUNIK > > DOSSIER.CLCLEUNIK
> where OL.TERMINE = 0
> and OL.NUMSOC = 1
> and OL.NUMDEP = 1
> and DOSSIER.DSCLEUNIK = OL.DSCLEUNIK
>
> cette requete fonctionne sur HF7 mais pas sur MySQL 4.0.20c !
> PS: Je suis en train d'essayer de migrer une grosse appli HF7 -> MySQL

et

> rares sont les requetes compatibles. Je croyais que SQL etait un langage
> standardisé !!!!!!!!
>
>

I.G.LOG wrote:

Bonjour,
Apres essais, le probleme vient de HExecuteRequeteSQL() ! En effet,
avec SQLExec() je n'ai plus d'erreur MySQL:

MySQL HExecuteRequeteSQL(lReq,lCond) // Fonctionne avec HF mais
pas avec MySQL !!!

L'inconvénient c'est qu'à chacun de tes posts tu change la requete donc j'ai
un peu de mal à suivre. La requete que tu donnais juste avant posait un pb.
Pb résolu avec la classe de Eric qui permet de mettre en forme ta requete.

Pour résumer, il faut utiliser SQLExec() et pas HExecuteRequeteSQL().

La migration HF -> MySQL s'avere de plus en plus difficile ! J'espere
que SQLManagerX va nous "sauver", notamment avec la fonction
SQLRecupereExec qui permet (je crois) de s'affranchir des SQLLitCol()
(avec SQLLitCol, si on change l'ordre des champs dans le select > bonjour les degats !)

Pourquoi avoir une migration difficile ? Elle n'est pas sans investissement
mais elle vaut le coup.

Autre probleme inquietant: Christian m'a contacté apres avoir migre
sa base sous MySQL avec SQLConvert. "je ne pas modifier les
enregistrements importés (seulement ceux créés par elle.. Et je n'ai
qu'un seul utilisateur pour Mysql !!)"

Je lui ai répondu dans son fil en lui posant des questions mais je n'ai
toujours pas de réponses. Si tu peux le réveiller.

Pour ma part, je n'en suis pas encore là (je ne teste que les lectures
actuellement). Mais, avant que je me lance completement, quelqu'un
a-t-il une info sur ce problème ?

Nous avons migrer une application de gestion commerciale COMPLETEMENT. Je
pense que si mes utilisateurs ne pouvaient pas modifier leures anciennes
données j'aurai entendu parler du pays! Je pense que cela vient plus de sa
gestion des "binaires".

--
Emmanuel

Bonjour, manu


"Manu" <el@netcourrier.com> a écrit dans le message de news:
cc0frc$hh2$1@reader1.imaginet.fr...

I.G.LOG wrote:
> Bonjour,
> Apres essais, le probleme vient de HExecuteRequeteSQL() ! En effet,
> avec SQLExec() je n'ai plus d'erreur MySQL:
>
> MySQL HExecuteRequeteSQL(lReq,lCond) // Fonctionne avec HF mais
> pas avec MySQL !!!

L'inconvénient c'est qu'à chacun de tes posts tu change la requete donc

j'ai

un peu de mal à suivre. La requete que tu donnais juste avant posait un

pb.

Pb résolu avec la classe de Eric qui permet de mettre en forme ta requete.

> Pour résumer, il faut utiliser SQLExec() et pas HExecuteRequeteSQL().

> La migration HF -> MySQL s'avere de plus en plus difficile ! J'espere
> que SQLManagerX va nous "sauver", notamment avec la fonction
> SQLRecupereExec qui permet (je crois) de s'affranchir des SQLLitCol()
> (avec SQLLitCol, si on change l'ordre des champs dans le select > > bonjour les degats !)

Pourquoi avoir une migration difficile ? Elle n'est pas sans

investissement

mais elle vaut le coup.

> Autre probleme inquietant: Christian m'a contacté apres avoir migre
> sa base sous MySQL avec SQLConvert. "je ne pas modifier les
> enregistrements importés (seulement ceux créés par elle.. Et je n'ai
> qu'un seul utilisateur pour Mysql !!)"

Je lui ai répondu dans son fil en lui posant des questions mais je n'ai
toujours pas de réponses. Si tu peux le réveiller.

bizarrememnt je crois que l'acces natif de pcsoft utilise un user bizarre
car avec MySQL4wd pas de souci pour relire et modifier les infos envoyer par
SQLManagerX Converter. tout cela me parait bizarre, quelqu'un a til deja
rencontrer
ce probleme ? visiblement ca se produit avec l'acces natif de PCSOFT

> Pour ma part, je n'en suis pas encore là (je ne teste que les lectures
> actuellement). Mais, avant que je me lance completement, quelqu'un
> a-t-il une info sur ce problème ?

Nous avons migrer une application de gestion commerciale COMPLETEMENT. Je
pense que si mes utilisateurs ne pouvaient pas modifier leures anciennes
données j'aurai entendu parler du pays! Je pense que cela vient plus de sa
gestion des "binaires".

il faudrait voir si c'est effectivement seulement avec l'acces natif de
PCSoft que cela se produit

--
Emmanuel

>> [CUT]

bizarrememnt je crois que l'acces natif de pcsoft utilise un user
bizarre car avec MySQL4wd pas de souci pour relire et modifier les
infos envoyer par SQLManagerX Converter. tout cela me parait bizarre,
quelqu'un a til deja rencontrer
ce probleme ? visiblement ca se produit avec l'acces natif de PCSOFT

Pourquoi mettre en frontal les 2 accès natifs en présentant une
incompatibilité au niveau des données ? Pour moi, en SGBD standard tu te
connectes avec un USER/PWD. Que tu te connectes avec CMySQL4WD, l'accès
natif de l'éditeur, phpMyAdmin ou tout autre frontal, tu as les MEMES DROITS
(pivilèges) pour un utilisateur donné. Un update reste un update. A la
rigueur que l'utilisateur n'ai pas les droits d'insertions ou de modif dans
une table c'est possible mais les droits ne sont pas à l'enregistrement!

J'ai déjà testé mes données avec l'accès de l'éditeur sans problèmes (en
Juin 2003 si je me souviens bien).

Attendons les réponses à mes questions, ensuite nous pourrons continuer
notre enquête.

--
Emmanuel

Bonjour,

Nous avons migrer une application de gestion commerciale COMPLETEMENT. Je
pense que si mes utilisateurs ne pouvaient pas modifier leures anciennes
données j'aurai entendu parler du pays! Je pense que cela vient plus de sa
gestion des "binaires".

Qu'entendez vous par "binaires" ?

I.G.LOG a utilisé son clavier pour écrire :

Bonjour,

Nous avons migrer une application de gestion commerciale COMPLETEMENT. Je
pense que si mes utilisateurs ne pouvaient pas modifier leures anciennes
données j'aurai entendu parler du pays! Je pense que cela vient plus de sa
gestion des "binaires".

Qu'entendez vous par "binaires" ?

Oui effectivement car on ne peut considérer les blob et txt comme du
binaire.

Est-ce que c'est du longblob ?

--
Eric Roumégou
http://cerbermail.com/?TSoulBerPA
(cliquez sur le lien ci-dessus pour me contacter en privé)

I.G.LOG wrote:

Apres essais, le probleme vient de HExecuteRequeteSQL() ! En effet, avec
SQLExec() je n'ai plus d'erreur MySQL:

Bingo !

"Gégé" <gerard.menvussa@ifrance.com> a écrit dans le message de
news:cc18mt$gqm$1@aphrodite.grec.isp.9tel.net...

I.G.LOG wrote:
> Apres essais, le probleme vient de HExecuteRequeteSQL() ! En effet, avec
> SQLExec() je n'ai plus d'erreur MySQL:

Bingo !

Bonjour,

Précision (p'tet importante): en utilisant HExecuteRequeteSQL avec l'option
hRequeteSansCorrection on arrive a un comportement identique a SQLExec()
(qui marche donc avec MySQL)
Mais... d'après les docs de PCSoft, SQLExec() est plus rapide que
HExecuteRequeteSQL() sur acces natif mais moins rapide (que
HExecuteRequeteSQL) sur HF ! (choisir donc en fonction de sa base); confirmé
par mes tests !