Discussion :

[Hibernatus34]

Bonjour,

Sur WD17, je dois développer un projet avec HF classic.
J'ai du code qui fait ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
sReq est chaîne = [
UPDATE MonFichier
SET
    RubriqueNonClé = 'Bob'
WHERE
    Identifiant <> '42'
]
 
HLitRecherchePremier(MonFichier, Identifiant, "42")
Trace(MonFichier.Identifiant)
HExécuteRequêteSQL(sdReq, hRequêteDéfaut, sReq)
Trace(MonFichier.Identifiant)

Et la trace me donne 2 identifiants différents.
Est-il normal pour HF que les requêtes SQL fichent en l'air le contexte HF ?
Identifiant est une clé unique de type texte non-null.

Pour moi c'est un bug très grave, mais n'ayant pas l'habitude de HF...

Merci d'avance.

[Bowen]

Je crois que j'allais dire une bêtise aussi grosse que moi...
Oui, le programme utilise le contexte local du fichier pour effectuer l'UPDATE.
(au moins en HF Classic, peut-être même en C/S, mais je ne suis pas certain)

Donc c'est normal, tu te retrouves sur le dernier enregistrement avec Identifiant <> '42'

[Hibernatus34]

Merci.
Je l'ai signalé comme bug au support technique, parce que ça me paraît aberrant.
Quand on exécute un SELECT, le résultat est parcouru via la source de données, et de tous les fichiers concernés (par jointure), aucun ne perd son contexte.
Quand on exécute un UPDATE, c'est la même fonction, on passe aussi une source de données, donc je ne vois pas pourquoi je devrais gérer une sauvegarde de contexte. Il n'y a aucun avantage à ce fonctionnement.

[Arnaud B.]

Bonjour,

As tu eu une réponse du ST ?

Cdlt, Arnaud.

[EDM-TAHITI]

Hello,
Il reste à mon sens un test à effectuer avec la requete sql qui est différente de la fonction hlitpremier.....
Utilisation de l'[ORDER BY identifiant]. En effet, il n'est pas précisé dans le requetage et la requete prend le premier enreg de trouvé, sans soucis de l'indexation puisque non indiqué...
A vous lire sur le résultat...
Cordialement
Eric