Discussion :

[L.nico]

Bonjour à tous,

je souhaite savoir si vous aussi vous rencontrez ce genre de problèmes.
Je fais actuellement un audit sur un applicatif windev et il y a parfois dans le code des requêtes de type UPDATE exécutées par lot (donc séparées par des ; )
Aucun problème sur ce genre de code qui me parait normal.
Cependant, en y regardant de plus près il y a parfois des requêtes du genre :

Code SQL :

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

1
2
UPDATE NomTable SET STOCK=STOCK+2 WHERE KEY=1;
UPDATE NomTable SET STOCK=STOCK+2 WHERE KEY=2;

Pas de problème en fichier plat mais en C/S l'execution des 2 requêtes simultanément donne +4 sur les 2 lignes.
en fait il exécute chaque requête autant de fois que le nombre de lignes du bloc.
Je viens d'envoyer un projet exemple à PC SOFT que je joins à ce fil de discussion.
Peut-être que je ne fais pas les choses correctement mais ce problème est pour moi très important car il ne nous permet pas de faire des update en bloc ....
Parfois vous avez besoin de mettre à jour 1000 lignes d'un coup, si pour 1000 lignes il execute 1000000 de requêtes ça fait mauvais genre ....
Sans compter que dans mon exemple, du fait de la multiplication des exécutions, les résultats sont faussés ...
que pensez-vous de tout ça ? je suis bien sûr ouvert à la discussion et à la méthode.
Merci par avance pour vos réponses,
Bonne journée à tous,

Nicolas

EDIT : Il faut rajouter un HCreationSiInexistant dans le cas du Test C/S. Je l'avais fait à la main donc zappé dans le projet.

[tatayo]

Bonjour,
Avec les données de l'exemple, je vois ceci:

Code sql :

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

1
2
 
UPDATE NomTable SET STOCK=STOCK+2 WHERE KEY in (1,2)

Mais j'imagine que l'exemple est simplifié.
Par contre on peut faire ceci, pour ajouter une valeur différente en fonction de la valeur de KEY:

Code sql :

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

1
2
 
UPDATE NomTable SET STOCK=STOCK+(case key when 1 then 10 else 20 end) WHERE KEY in (1,2)

Par contre je suis étonné que le résultat avec 2 requêtes soit faux. Pour moi il s'agit clairement d'un bug.

Tatayo.

[L.nico]

Bonjour Tatayo,

Merci pour ta réponse,
tout à fait d'accord avec tes exemples et oui ce sont des exemples simplifiés.
Pour moi aussi c'est un bug, mais je trouve assez étrange que personne n'en parle car il est quand même relativement important.
Le problème existe aussi en Windev 22 (pas testé dans les versions précédentes)


Nicolas

[tbc92]

Et tu es sûr que chacun des 2 update en question est lancé une seule fois ? J'ai des gros doutes. Mon petit doigt me dit qu'il y a une boucle pour key = 1 a 2 quelque part... et qu'on mélange de la programmation classique (basée sur des boucles), avec une logique SQL.

[L.nico]

Et tu es sûr que chacun des 2 update en question est lancé une seule fois ? J'ai des gros doutes. Mon petit doigt me dit qu'il y a une boucle pour key = 1 a 2 quelque part... et qu'on mélange de la programmation classique (basée sur des boucles), avec une logique SQL.

Bonjour TBC92
Merci pour ta réponse,

Le test en fichier plat montre bien que chaque requête est exécutée une fois. Mais pas en C/S.
Et je fais ce genre de requêtes en SQL server depuis un paquet de temps et ça marche plutôt bien.
C'est peut-être une limitation Hyperfile c'est ce que j'aimerai bien comprendre.
Mais au vu de la différence de comportement ça ressemble plus à un bug.

[Invité]

Si votre vrai code ressemble à celui qui a été fourni dans l'exemple, il serait plus intéressant de construite la requête UPDATE de la manière suivante :

Code :

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

1
2
update MaTable set STOCK=Stock+5
WHERE id in (1,2,3,10,12)

[L.nico]

Bonsoir Romulus,
Merci pour ton intérêt,
je comprends parfaitement ta remarque mais il y peut y avoir plusieurs centaines de lignes UPDATE avec des valeurs de stock différentes ex :

Code sql :

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

1
2
3
UPDATE NomTable SET STOCK=STOCK+8 WHERE KEY=1;
UPDATE NomTable SET STOCK=STOCK+4 WHERE KEY=2;
UPDATE NomTable SET STOCK=STOCK+12 WHERE KEY=3;

Pour ma part l'objectif de cette discussion n'est pas de discuter la nature/pertinence du code, mais de savoir si ce comportement d'hyperfile est un bug ou une restriction.
Je penche bien sûr fortement pour le bug.
Merci pour vos messages

[tbc92]

Et une question sur le code... Es tu dans la configuration 1 ou 2 ?

Code :

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

1
2
3
4
5
6
req = [
UPDATE NomTable SET STOCK=STOCK+8 WHERE KEY=1;
UPDATE NomTable SET STOCK=STOCK+4 WHERE KEY=2;
UPDATE NomTable SET STOCK=STOCK+12 WHERE KEY=3;
]
Hexecuterequete(req)

ou bien

Code :

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

1
2
3
4
5
6
7
8
req = [
UPDATE NomTable SET STOCK=STOCK+8 WHERE KEY=1;
UPDATE NomTable SET STOCK=STOCK+4 WHERE KEY=2;
UPDATE NomTable SET STOCK=STOCK+12 WHERE KEY=3
]
pour toute chaine sch de req separee par ";" 
  Hexecuterequete(req)
fin

[L.nico]

Bonjour,
dans la configuration n° 1 , le but étant de minimiser les allers retours serveurs et de faire une action commune update sur des lignes multiples.
Et je le reprécise à nouveau, aucun souci en fichier plat Hyperfile ou en microsoft SQL Server. Le problème ne se pose qu'en Hyperfile C/S.
Merci pour votre intérêt.
Dans tous les cas je mettrais à jour ce sujet lorsque j'aurai les éclairages ( ) de PC Soft.

Bon Week end

[L.nico]

Bonjour,
Voici la position de PC Soft.
"La parser SQL n'accepte pas les requêtes multiples donc ce n'est pas autorisé" ...
Il va sans dire que j'ai un peu insisté et ils ont donc cherché quand même pour finalement me trouver une solution mais sans me donner une réelle explication.
Pour que les requêtes multiples fonctionnent, il faut passer la connexion à l'instruction HexecuteRequeteSQL ex :

Code :

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

HExécuteRequêteSQL(NomRs,NomdelaConnexion,hRequêteSansCorrection,QueryBloc)

Pour ma part je ne précisais pas la connexion parce que c'était la connexion active,
ils n'ont pas su me dire pourquoi ça part en vrille avec la connexion active non précisée.
Cependant, j'ai maintenant un moyen de contournement donc je considère ce sujet comme résolu.
Merci à tous pour votre participation,

Nicolas