Discussion :

[jjacques68]

Hello tout le monde !

Je rencontre un soucis que je ne comprends pas.

Dans mes analyses, lorsque je crée des liaisons entre fichier, je fais bien attention à sélectionner les bonnes options qui vont bien, de manière à pouvoir effectuer des suppression en cascade :



sur le serveur HFSQL :




Si j'utilise la propriété MaLiaison..RègleSuppression, j'ai bien en réponse "hIntégritéCascade" (constante 2022)


Mais impossible de le faire fonctionner !!

J'ai essayé avec :

- HLitRecherchePremier() sur la première table, suivit d'un HSupprime() (avec les option de vérification de l'intégrité)
- via une requête de suppression (toujours sur la première table)

Mais rien y fait !
Seul l'enregistrement dans la table "parent" est supprimé, les données "enfant" qui héritent ne le sont pas !
Bien-sûr les index correspondent bien.

Quelqu'un à une idée ?

Parce que là je sèche
Dans mon exemple il y a 2 tables, mais en réalité il y en a beaucoup plus...
Et pour supprimer un enregistrement, ça devient galère...

Merci pour votre aide !!

[tbc92]

As-tu testé si tout ça marche quand tu as la configuration simple : seulement 2 fichiers ?

Si ça ne marche pas avec 2 fichiers, c'est que tu coches pas ce qu'il faut où il faut ...
Mais si ça marche sur 2 fichiers, et pas au-delà, ça veut peut-être (????) dire que le principe des cascades, ce serait limité à 1 niveau ???

Personnellement, je n'aime pas supprimer des lignes. Je ne jette jamais rien.
Je préfère un flag 'Ligne-supprimée' , ou une colonne de type Date : 'Date de fin de validité'.

[jjacques68]

je vais tester ça demain, avec un nouveau projet tout simple,
et te dirais ce que ça donne...

[Voroltinquo]

Bonjour,
Cela provient aussi peut être d'une autre contrainte sur la table "Fille" qui interdit la suppression.

[jjacques68]

@Voroltinquo : je ne pense pas, je vérifierai quand même...

[jjacques68]

oh ben zut, ça marche !!!
Et sur 3 tables en cascades !!

J'ai mis exactement les mêmes paramètres ???

[jjacques68]

Voici mon essai :



avec les contraintes :



et donc ça fonctionne très bien !

Mais je ne comprends ce qui peut clocher dans mon autre projet...
ça c'est problématique...

[tbc92]

Ca ressemble à un bug côté HFSQL
Peut-être que l'ordre dans lequel tu crées les contraintes a une importance.

Si HFSQL regarde toutes les instructions de cascade, dans l'ordre de création ... ça peut expliquer ton problème.

[jjacques68]

Alors je viens d'essayer autre chose :

J'ai créé un nouveau projet,
dans lequel j'ai ajouté une connexion HFSQL sur l'analyse en question.

Et bien là ça fonctionne très bien ?!
La suppression en cascade semble bien se comporter !!

va comprendre...


Et d'ailleurs j'ai du coup un soucis (logique vu mes paramètres) :



J'interdis dans une liaison une suppression.
ça m'embête de l'interdire.
Je pourrais supprimer l'enregistrement parent tout en laissant l'enfant avec l'ID du parent, même ci-celui-ci n'existe plus.

MAIS :

Je trouve ça moche.
Dans les options de la liaison, on peut le faire :



Il y a aussi cette option :



Mais que cela signifie, il prend un ID au pif parmi les existant ?

Quelle serait la méthode "propre" ?

[tatayo]

Bonjour,
Pour moi garder les lignes de la table enfant avec un id "orphelin" revient à dézinguer l'intégrité de la base… Donc c'est moche.
Donc cette option n'est (de mon point de vue) même pas envisageable, puisqu'elle va à l'encontre de l'objectif des règles d'intégrité.

Concernant le dernier cas, la valeur affectée à la colonne des lignes "orpheline" est (si HFSQL fait comme SqlServeur) la valeur par défaut de la colonne rubrique, comme définie dans la description de la table du fichier.

En fait il existe à ma connaissance 4 options dans la clause ON DELETE:

1. CASCADE
2. RESTRICT
3. SET NULL
4. SET DEFAULT

Pour ma part je n'utilise que les deux premières, mais pour la dernière on peut créer un enregistrement "poubelle", vers lequel vont pointer les lignes dont l'enregistrement parent est supprimé,

Exemple concret: avec le RGPD, je suis susceptible de supprimer une fiche client.
Pour éviter les null dans les idclients, je vais créer un "client anonyme", et toutes les clés étrangères IdClient de toutes les tables auront comme valeur par défaut l'Id de cette ligne, et la contrainte sera ON DELETE SET DEFAULT.

Ainsi quand je vais supprimer une fiche client, tous les documents, tous les historiques, toutes les stats vont pointer vers ce client anonyme, sans avoir à le faire à la mano partout dans le code.
Et je n'ai pas de null qui se baladent, ce qui va simplifier les requêtes concernées.

Tatayo.

[jjacques68]

@tatayo, c'est très clair, merci.

Mais il me semble pas avoir la possibilité de définir l'enregistrement "poubelle".
Je vois nul part le "ON DELETE SET DEFAUT"...

[tatayo]

IL s'agit de la dernière option que tu présentes dans ton mail.
La liste que j'ai donné correspond au standard SQL, il faut voir comment PcSoft les a "renommés".

Tatayo.

[jjacques68]

Ok mais pas moyen de définir l'enregistrement "défaut" avec cette option...

[Voroltinquo]

Il suffit, dans la description de ta FK d'affecter une valeur par défaut. NULL est une bonne valeur. Il faut toutefois prendre soin de cocher NULL supporté dans la description de ta table.

[jjacques68]

ahhhh ok !!

Il prendra la valeur par défaut définit dans la description de la rubrique dans le fichier FIC !!

Je comprends !!

nickel !

merci !

[Voroltinquo]

Par ailleurs, en C/S, c'est le serveur qui prend en charge les contraintes d'intégrité. Il ne les "connaît" qu'une fois la table créée via HCréation ou HCréationSiinexistant.
Cela explique peut être pourquoi tu avais tes problèmes de suppression en cascade.

[jjacques68]

Il ne les "connaît" qu'une fois la table créée via HCréation ou HCréationSiinexistant.

Normalement, toutes les tables sont crées sur le serveur HFSQL car elles sont toutes utilisées...

[Voroltinquo]

Elles sont créées ou elles existent. Si ce n'est pas le serveur qui a fait le boulot (e.g. import de la structure) il ne prend pas en compte les contraintes.