Hello
n'y aurait-il pas une clé étrangère sur ta clé ?

Non j'ai pas de clé étrangère

Bonjour,

héé, je crois que la clé unique n'est pas modifiable
La solution est de mettre un ID_AUTOMATIQUE
n'est ce pas ???...

He ho

y pas qq'1 qui peux m'aider ???

Salut
je n'ai pas encore WinDev, je ne peux donc répondre précisément à ta question.
néanmoins, une colonne, même si elle fait partie de la clé primaire, doit être modifiable (évidemment, en respectant les contraintes qui lui sont associées).
Cette impossibilité de modification risque de te faire prendre de trrrès mauvaises habitudes en manipulation de données. Et le jour où tu passeras vers une autre config (LAMP ou APEX par ex), tu vas te retrouver complètement déboussolé.
donc
- si l'impossibilité de modifier la clé vient de ton sgbd, changes-en
- si l'impossibilité de modifier la clé vient de WinDev, changes-en et signale-le nous, histoire de ne pas faire la même erreur que toi.

Pour être plus clair,
Dans l'analyse, j'ai modifié la Liaison entre les fichiers pour que :
- Règles de suppression : interdire la suppression d'un "Nom_1°Fichier", qui a au moins un "Nom_2°Fichier"
- Règles de Modification : Modifier la clé du "Nom_1°Fichier", et toutes clés reliées du "Nom_2°Fichier"

Exemple : j'ai les Deux Fichiers suivants
- PANNE(CD_PANNE, LIB_PANNE)
- CAUSE_PANNE(CD_CAUS_PANNE, LIB_CAUS_PANNE)

la relation est AVOIR_CAUSE_PANNE avec (0,n) des deux côtés
Tous les champs sont de type TEXTE

dans l'ajout, ça marche très bien. mais lorsque je veux modifier avec HModifie(NOM_FICHIER,NUM_ENREGISTREMENT), ça marche pas.

sachant bien que dans d'autre projet d'auto-formation, la modification se passe bien.
ALORS, qu'est ce que vous en dites

Bonjour,

je prends bonne note de 1) la suppression du père est interdite s'il y a des enfants et 2) les enfants sont modifiés si le père est modifié.
donc, la modification de la "clé" devrait fonctionner.
si ça continue à refuser de fonctionner, c'est que 1) le logiciel est mal foutu (mais ça se saurait) 2) la base de données est mal foutue (ça se saurait aussi) 3) il y a une liaison "cachée" qui n'a pas été modifiée pour adopter les règles ci-dessus.
... et, ne serait-ce pas à cause d'une table intermédiaire (rendue nécessaire par le (0,n) dans les 2 sens) entre panne et cause_panne ?

Et si l'on reprenait sa casquette d'analyste ? on irait dire qu'une panne ne peut avoir qu'une cause ; et si la panne a plusieurs causes, c'est qu'en fait, il y a plusieurs pannes ;-)

Je crois que c'est moi le foutu
c'est juste la condition de modification que j'ai raté
il fallait faire :

SI ch="modif" ALORS
HLitRecherchePremier(PANNE,CD_PANNE,Fn_PANNE.CD_PANNE)
SI PAS HTrouve() ET CD_PANNE <> sANCIEN_CD_PANNE ALORS
EcranVersFichier()
HModifie()
// Message d'information
Info("Modification effectuée avec succès")
SINON
Info("Ce Code existe déjà !.")
RepriseSaisie(Fn_PANNE.CD_PANNE)
FIN
FIN

Avant, voilà la faute commise :

SI ch="modification" ALORS
HLitRecherchePremier(Marque,CD_MARQUE,Fn_Marque.CD_MARQUE)
SI HTrouve() ET Fn_PANNE.CD_PANNE <>sANCIEN_CD_PANNE) ALORS
Info("Cette Panne existe déjà !.")
RepriseSaisie(Fn_PANNE.CD_PANNE)
SINON
SI HTrouve() ET Fn_PANNE.CD_PANNE = sANCIEN_CD_PANNE ALORS
EcranVersFichier()
HModifie()
// Message d'information
Info("Modification effectuée avec succès")
FIN
FIN
FIN


En tous cas, merci pour l'intérêt accordé de votre part....