Discussion :

[iceuponfire]

Sans Paul ni Mickey, avec une requête de ce genre ça doit passer:

Code sql :

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

1
2
3
4
5
6
 
insert into ti(c1,c2)
select c1,c3
from t1 inner join t2 on x=y
where z=w
update duplicates

Tatayo.

"ON DUPLICATE KEY"

[michel.souris]

J'ai également testé le on duplicate key voyant que la syntaxe proposé par tatayo ne passe pas... mais c'est pareil sur HF !!!!

en tout cas j'adore le coté pratique et compact de cette syntaxe... si seulement je pouvais m'en servir.... Oracle tu me manques...

[iceuponfire]

J'ai également testé le on duplicate key voyant que la syntaxe proposé par tatayo ne passe pas... mais c'est pareil sur HF !!!!

en tout cas j'adore le coté pratique et compact de cette syntaxe... si seulement je pouvais m'en servir.... Oracle tu me manques...

Il y a "on duplicate key" pour mysql, ou voir aussi la clause "merge" pour d'autres SGDB, autrement en hfsql la liste des instructions implémentés http://doc.pcsoft.fr/fr-FR/?2034006 je ne vois rien qui puisse répondre à cette problématique, il faudra peut être utiliser la solution sus-cité Hibernatus34 ou alors gérer l'exception/erreur avec du code perso ou des fonctions h comme HErreurDoublon http://doc.pcsoft.fr/fr-FR/?3044077&...ublon_fonction.

[tatayo]

En tout cas j'adore le coté pratique et compact de cette syntaxe... si seulement je pouvais m'en servir.... Oracle tu me manques...

Tu peux. Il suffit de ne pas utiliser HF

On peux aussi demander un support complet de la norme SQL92 pour la version 20...

Tatayo.

[michel.souris]

Tu peux. Il suffit de ne pas utiliser HF

On peux aussi demander un support complet de la norme SQL92 pour la version 20...

Tatayo.

Ahahah !!! je ris... jaune mais je ris !

non sans déc, j'ai pas le choix sinon ça serait tout vu... c'est un produit racheté par une boite qui m'a embauché pour le maintenir... donc 6 ans d'historique, plus de 1000 sites installés.. pas le choix des technos malheureusement... et si tu savais tout l'historique que je me tape, HF n'est qu'un détail !

disons que dans d'autres contexte je repenserais cette requête upsert, concept qui m'était inconnu.

quand au support complet de la norme sql92 en 2020.... j'y crois pas, surtout quand je vois que 75% des dév continue à faire du sql86....

[Hibernatus34]

Code :

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

1
2
 
UPDATE T1 INNER JOIN T2 ON T1.idT1=T2.idT1 SET T1.idT2=T2.idT2

Le sujet de ce fil est les bugs non corrigibles, et celui que vous signalez, c'est à dire l'erreur de parsing, n'existe pas et serait corrigible...

Ceci étant dit, votre requête me paraît fausse, elle devrait ressembler à ceci :

Code :

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

1
2
 
UPDATE T1 SET T1.idT2 = T2.idT2 FROM T1 INNER JOIN T2 ON T1.idT1 = T2.idT1

Ensuite, il y a d'autres manières, par exemple :

Code :

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

UPDATE T1 SET T1.idT2 = (SELECT T2.idT2 FROM T2 WHERE T1.idT1 = T2.idT1) WHERE EXISTS (SELECT * FROM T2 WHERE T1.idT1 = T2.idT1)

[michel.souris]

Je vous propose de demander à un modo de supprimer mes posts s'ils vous dérangent.

D'autres erreurs de parsing ont été signalées ainsi que des bugs corrigibles. Suis-je la goutte d'eau ? Le fait d'ouvrir un post ne vous en donne pas la propriété. Ouvrez votre forum pour ça.

De plus le bug existe même s'il ne vous touche pas (WD<=17).

Votre première syntaxe n'est pas du SQL92;

La seconde n'est pas supportée par HF. J'ai tenté une requête similaire (ce que j'ai précisé sur le forum).

Merci pour votre animosité depuis le début de vos interventions sur ce sujet, ça fait un peu d'animation. Peace.

PS : si vous voulez évitez les dérives, commencez par vous contenir vous même.

[Hibernatus34]

Inutile de vous vexer, je n'ai rien contre vous.
Je vous signale que vous vous trompez (de sujet et de bug), c'est tout, et ça arrive à tout le monde, sans arrêt. Moi compris, bien évidemment.

[michel.souris]

Franchement, je n'aurais pas du dire "animosité" mais "antipathie"... qui est complètement subjectif.

Que vous trouviez mon post inintéressant je peux le concevoir... que vous n'admettiez pas que le bug existe... j'ai un peu plus de mal.

De plus j'ai la vague impression que vous n'avez pas lu mon post.
Enfin les bugs sont presque tous corrigibles donc là je vous suis pas du tout.

[Hibernatus34]

Je vais essayer d'être plus clair (et moins antipathique ? difficile, par écrit) :

- D'après ce que j'ai compris, le bug que vous souhaitiez signaler était un bug de parser, où HF trouverait des mots-clés SQL dans le contenu d'une chaîne littérale. Comme indiqué à la page précédente, j'ai essayé de reproduire le bug dans WD18 et je n'ai pas réussi.

- Par "bug non corrigible", j'entends un bug que le support technique refuse de faire corriger, souvent parce que ça causerait des "régressions", ou parce que c'est une erreur de conception qui ne les empêche pas de dormir et qui est contournable. J'ai envoyé des dizaines de rapports de bugs à PC Soft, et ici je liste ce sur quoi je n'ai rien pu faire, soit par refus du S.T., soit par fatalité. (comme sur l'inversion de Hauteur/Largeur dans dCopieImage, inutile de déranger le S.T., c'est fichu)

Votre poste n'est pas inintéressant, et je me suis intéressé au(x) problème(s) que vous posez, sinon je n'aurais pas répondu par un lien sur MERGE, la méthode pour un UPSERT, et la syntaxe d'un UPDATE avec jointure.

[Arnaud B.]

bonjour,

Je reviens sur la requete WDR complétée ensuite dans une chaine (Arnaud B je crois).
Je n'ai pas bien compris ce qu'il faut faire pour intégrer cette requete à la table une fois transformée en chaine.
Quelqu'un peut m'expliquer ?

Moi je n'utilise pratiquement jamais les WDR et pour remplir une table je passe par un hexecuterequetesql et un POUR TOUT.

Merci

Tu crées une requete WDR que tu enregistres normalement, avec la clause SELECT qui va bien.

Peu importent les autres clauses puisque tu va réécrire le code SQL ensuite, il s'agit juste d'avoir les bons noms de rubriques dans la requête afin de pouvoir les relier aux colonnes de la table, ou d'une combo.

Attention, il faut quand même que ta requete soit correcte, sinon elle ne sera pas reconnue par Windev et tu ne pourra pas relier les rubriques aux champs (remarque : pour savoir si une requete est reconnue par WIndev, quand tu l'enregistre, s'il arrive à visualiser les rubriques Select dans le graphe de représentation de la requête, c'est que c'est bon).

Ensuite, tu exécute cette requete AVEC ton VRAI code SQL, en utilisant
HExecuterequeteSQL(nom_de_ta_requete_WDR, code_sql)

J'utilise systématiquement cette méthode et cela marche impec, même si quelquepart, on fait le travail en double pour le SELECT.

Mais au moins, on peut avoir le databinding ET le code sql qu'on veut.

[Arnaud B.]

Ahahah !!! je ris... jaune mais je ris !

non sans déc, j'ai pas le choix sinon ça serait tout vu... c'est un produit racheté par une boite qui m'a embauché pour le maintenir... donc 6 ans d'historique, plus de 1000 sites installés.. pas le choix des technos malheureusement... et si tu savais tout l'historique que je me tape, HF n'est qu'un détail !

disons que dans d'autres contexte je repenserais cette requête upsert, concept qui m'était inconnu.

quand au support complet de la norme sql92 en 2020.... j'y crois pas, surtout quand je vois que 75% des dév continue à faire du sql86....

Juste pour apporter un complément d'information :
- on en est à la norme SQL:2011 (donc SQL-86 c'est loin ! 25 ans !)
- on utilise souvent des fonctionnalités qui n'ont été normalisées qu'après SQL-86 (par exemple : OFFSET, FIRST_VALUE...) mais comme ces fonctions ont été implémentées dans la plupart des SGBD bien avant d'être normalisées, on ne s'en rend pas compte...
- à ma connaissance, AUCUN SGBD ne supporte la totalité de la norme SQL-86 ou même SQL-92. Toutefois, ce qu'on demande à HF, c'est de supporter les fonctionnalités SQL-Core, celles qui sont depuis longtemps implémentées par tous les SGBD du marché...

Cdlt, Arnaud.

[bruno.a]

OK merci Arnaud je vais tester ça

[bruno.a]

Petite question Arnaud

Tu relies ta table au WDR dans l'intercalaire Contenu ?

Si oui comment ne pas executer la requete original mais celle modifier ?

[bruno.a]

c'est bon j'ai trouvé

je n'executais pas ma requete dans l'init de la table mais dans un bouton du coup je ne voyais tout mon fichier au lieu d'une partie avec mes conditions.

[Hibernatus34]

Bonjour,

Je rajoute 2 choses qui m'agacent :

1. Un membre global devient local :

Code :

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

1
2
3
4
5
6
7
8
CToto est Classe
GLOBAL
	g_sToto est chaîne // Global
	CONSTANT
		c_ValeurInitialeCompteur = -1
	FIN
	g_nCompteur est entier  // Local ou global, d'après vous ?
FIN

Réponse de WinDev et du Support Technique : local !
D'après le ST, c'est le comportement normal.
Le bug est lié à la présence de constantes avant la déclaration.
WD aurait pu interdire de les déclarer là, mais maintenant que c'est faisable, il faudrait le faire sans effets de bord !

2. dRedimensionne avec drHauteQualité
Le code suivant fonctionne :

Code :

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

dRedimensionne(imgImage, nLargeur, nHauteur)

Celui-là non :

Code :

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

dRedimensionne(imgImage, nLargeur, nHauteur, drHauteQualité)

La solution :

Code :

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

dRedimensionne(imgImage, nLargeur, nHauteur, drEtiré + drHauteQualité)

C'est pas si gênant une fois qu'on le sait, mais j'ai cru quelques minutes à un bug de mon application à cause de ce manque de logique de la part de PC Soft.
Il paraît intuitif et naturel de permettre de rajouter drHauteQualité en conservant le type de redimensionnement par défaut, surtout que le compilateur ne détecte pas d'erreur.

[Hibernatus34]

Deux autres :

1. En multithread le type Connexion peut vous faire réutiliser une connexion d'un autre thread sans que vous le vouliez.
Quand on crée une variable de type Connexion, sa propriété ..Nom prend un nom qui désigne la connexion globalement (ça rappelle les sources de données...).
Ce nom est basé sur le nom de la variable, dans le cas d'un élément de tableau c'est carrément une chaîne vide.
Si le nom est déjà utilisé, ou vide, il est corrigé avec l'ajout d'un chiffre.
Mais en lançant 2 threads je me suis trouvé avec 2 fois "m_cnxConnexion3", et les 2 threads utilisaient ainsi la même connexion sans que je le sache. (vérifié avec le @@SPID dans SQL Server)
Là, ce n'est qu'un bug, mais j'en ai marre de faire des projets de repro, et ce bug est dû à une faute de conception.
Imaginez que les 2 connexions ne soient pas sur la même base...
Et de toute façon, quand vous faites certaines modifications sur le type Connexion, vous provoquez une déconnexion, et pouvez donc planter votre 1er thread...

2. En multithread, toutes les fonctions H- sont synchrones, même sur des connexions différentes
Je lance une requête un peu longue dans un thread avec HExecuteRequêteSQL sur une connexion spécifique au thread.
A cause de cette synchro, dès que l'utilisateur provoque un HLitRecherchePremier, un HExecuteRequêteSQL ou autre, l'application se bloque jusqu'à ce que ma requête en tâche de fond soit terminée.
Notez que j'ai bien désactivé le mode "automatique" de synchro avec avec ThreadMode (une autre hérésie...).

[Invité]

Bonjour,

C'est vrai qu'en l'état actuel des choses (windev V 19), la gestion des threads de windev n'était pas terrible... J'en sais quelque chose car quand je suis passé de dotnet à wd l'année dernière et que j'ai voulu faire du multithreading, je me suis bien pris la tête... Alors qu'en dotnet avec les tâches c'est simple et cohérent (enfin de mon point de vue en tous cas).
J'avais aussi à utiliser des requêtes dans les autres threads... Sur le papier je pensais avoir compris la différence entre recopie de contexte HF ou pas recopie mais en pratique, j'ai du faire "pas de recopie" sinon ça figeait... Après moultes tests je n'ai toujours pas compris ce qui se passe vraiment lors d'une recopie immédiate du contexte HF dans un nouveau thread...

Cela dit PC soft annonce à ce sujet un changement dans la v20 avec un modèle de tâches très inspiré de dotnet... Serait-ce enfin la fin du calvaire de ceux qui, comme moi, souhaitent faire un vrai multitâches en wd sans se prendre la tête?

[Hemgé]

Bonjour,

HDécritFichier

A partir de l'exemple de la documentation, pour bien fixer le sujet :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
UnFichier est une Description de Fichier
UneRubrique est une Description de Rubrique
//CLIENT est une Source de Données est inutile <<<<<<<<<<<<<<<<<

// Description du fichier de données "CLIENT"
UnFichier..Nom = "CLIENT"  //<<<<<<<<<<<<<<<<<<<  une variable fait parfaitement l'affaire 
UnFichier..Type = hFichierNormal
UnFichier..CryptageFic = hCryptageStandard

// Description de la rubrique "NOM"
UneRubrique..Nom = "NOM"
...

// Description de la rubrique "PRENOM"
UneRubrique..Nom = "PRENOM"
...

// Valide la description du fichier de données 
HDécritFichier(UnFichier)
...
//On s'arrête ICI <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
// Création du fichier de données Client (reconnu car déclaré comme source de données)
//reconnu car déclaré comme source de données : INUTILE 
HCréation(CLIENT)

Si on s'arrête avant la création physique du fichier, comment savoir qu'une description (par programmation) d'un fichier existe déjà (s'il n'a pas été créé physiquement - répétition volontaire) ?
Ceci, dans l'optique de contrôler divers traitements : ne pas avoir deux descriptions de fichier ou de source de données de nom identique, avec les problèmes connus, éviter une erreur si on tente une opération sur un fichier qui n'a pas été décrit ou au contraire qui l'a déjà été dans le même traitement ou dans un autre etc ..?
Peu importe les motivations ou le bien-fondé du traitement que l'on veut effectuer, on va décrire ou on a décrit un fichier et on aimerait s'assurer de l'état de l'environnement.
Peu importe aussi qu'il ait été conseillé de rendre les noms uniques, on veut justement gérer une erreur potentielle.

A ma connaissance, il n'y a rien de prévu pour cela et je n'ai trouvé aucun biais ou bidouille.

Note :
Au passage, je signale que - en version 19 en tout cas - , il n'est pas/plus nécessaire de déclarer une Source de Données pour Déclarer, Créer et Mouvementer un fichier hors analyse.
On peut fonctionner avec une variable pour la déclaration/description et l'indirection pour qualifier les rubriques dans le code.

HAnnuleDéclaration

En travaillant sur HDécritFichier, il est apparu que HAnnuleDéclaration ne vérifie pas si le fichier cible existe ou, en tout cas, ne génère ni erreur ni warning si le fichier n’existe pas : qu’il s’agisse d’un nom tout à fait « Bidon » ou d’une déclaration déjà annulée.
Plus ou pire ( ?), il renvoie Vrai si le fichier n’existe pas (on pourrait considérer que le résultat est atteint puisque le fichier n’existe pas / plus, mais quand même … ! )

En fait, l'idée était, au sortir de la partie concernée de l'application, de vérifier que la description du fichier existait bien avant de l'annuler (puisqu'elle aurait pu échouer).
D'où la recherche d'un test sur l'existence (qui n'existe pas) et le test d'une éventuelle erreur en cas d'utilisation erronée de HAnnuleDéclaration.

Hemgé

[frenchsting]

@Hemgé,
J'ai mis un hcreationsiinexistant(CLIENT) et le contenu du fichier n'est pas effacé.

Mais je ne sais pas si c'est adapté à ton cas. Une autre astuce serait de passer par la triplette diabolique Halias / HchangeNom / HChangeRep avec une pincée de la doublette machiavelique fListeFichier / ffichierExiste.