Delete on CASCADE ?

Hello !

J'ai une analyse contenant une certaine quantité d'entités-faibles. J'ai paramétré mes liaisons de telle sorte qu'à la suppression de l'entité "mère", les suppressions se font en cascade.

Jusque là tout va bien tant que j'utilise les ordre H... ou que j'ajoute le hVérifieIntegrité à un HExécuteRequêteSQL.

J'étais par contre entrain de me demander pourquoi ou plutôt qu'est-ce qui justifie que le fait de taper une requête à la main par exemple dans le centre de contrôle HF C/S n'enclenche pas les cascades ?! :langue:

Dans HF, les requêtes passent outre les contraintes d'intégrité. UPDATE, DELETE, INSERT... Tu peux tout forcer.
A moins que dans le HExecuteRequeteSQL qui passe cet ordre tu n'ajoutes le paramètre hVérifieIntégrité.

C'est bien ce que je vois, mais je ne comprend pas trop cette philosophie. Si quelque part on a défini nos associations pour qu'elles se modifient ou suppriment en cascade, c'est bien qu'on a envie de se faciliter la vie, non ?

Alors ça... pour la philosophie, il faut s'adresser directement à PCSoft. Leurs choix ne dépendent que d'eux !
Il faut juste le savoir, les contraintes d'intégrité ne sont pas des contraintes absolues en HF.

D'après ce que j'ai compris, l'intégrité référentielle n'est pas défini au niveau du fichier, mais au niveau de l'analyse.

Le centre de contrôle HF C/S, qui ne demande pas à quelle analyse sont rattachés les fichiers, ne peut du coup pas appliquer les règles d'intégrités.

C'est l'inconvénient d'avoir des tables stockées dans des fichiers séparés, il n'est pas possible d'assurer l'intégrité de ces tables, les fichiers .fic pouvant être déplacés, remplacés et manipulés individuellement.

En gros l'intégrité référentielle est très sensible sous HF ou HF C/S.

DelphiManiac ce que tu dis es vrai pour HF Classic, mais pas pour HF/CS.
En classic,l'analyse est indispensable, vu qu'effectivement les fichiers sont gérés séparément.
En CS, les contraintes d'intégrités sont remontées au niveau du serveur. Elles sont donc gérées par le serveur HF lui même. L'analyse n'est plus nécessaire lors de l'exploitation de ces données. Le serveur connait les contraintes.
Pour autant, les ordres SQL directs ont la même règle dans les deux cas : ils ne suivent pas (par défaut) les contraintes d'intégrité.

@Bowen

Es tu sûr de ce que tu avances, à savoir que les règles d'intégrité sont remontées au niveau du serveur ?

C'est à dire que si je décrit un fichier par HDécritExterne (donc sans analyse) dans un projet Windev qui pointe vers fichier hébergé sur une base HF C/S, les règles d'intégrité vont être respectées.

D'autre part, si je remplace par exemple un fichier .fic manuellement (par une version antérieure par exemple) dans une base HF C/S, le moteur HF va me sortir une erreur d'intégrité dès que je vais accéder à cette base ?

Non ce n'est pas ce que j'ai dit.
Les contraintes d'intégrité sont bien remontées au niveau du serveur.
C'est à dire que les contraintes décrites dans l'analyse sont notées le fichier <_system\Integrity.FIC> sur le serveur. C'est ce dont le serveur se sert ensuite.
Je prends un exemple simple : Sur ma base de données, j'ai un programme PC et un sur des PDA (en wifi donc).

• Sur le PC, j'ai l'analyse. Comme ça quand je fais une MAJ de la structure, la modification des fichiers se fait par mon appli.
• Sur les PDA, je n'ai pas utilisé l'analyse. Je connecte mes fichiers par des HDeclareExterne. Pourtant, toutes mes contraintes sont bien respectées.

En ouvrant le fichier Integrity.FIC tu comprendras la différence avec le cas du HDécritExterne : Un fichier décrit par HDecritExterne ne sera pas relevé dans le Integrity.FIC. Il n'aura donc aucune contrainte appliquée.

Je comprend plus ou moins ce que tu dis, mais le principe même de stockage des tables dans des fichiers séparés n'aide pas à maintenir une intégrité référentielle, la base n'étant pas un tout unitaire qui est ouvert et vérifié lors de l'accès à un des éléments de ce tout.

Je reste bien plus confiant sur le principe utilisé par les bases Jet, pour autant largement décrié, quand à la capacité de maintenir une base intègre.

Ah je n'ai pas dit que c'était une solution idéale non plus, je décris simplement ce que je sais.
Et pour préciser ta remarque, les contraintes ne sont pas vérifiées lors de l'accès, mais lors de l'écriture (je veux dire qu'elles ne sont pas vérifiées en lecture). C'est aussi le cas pour Access, puisque tu le prends comme exemple, comme pour toutes les autres bases de données (et heureusement).

@lazariel : tout ça a répondu à ta question ?

Tout à fait. Je comprend mieux le pourquoi du comment. Ma curiosité n'est pas tout à fait satisfaite, mais au moins je n'ai plus à pester de la même manière et je peux amener de l'eau à mon moulin pour changer de SGBD sur les développements futurs :ccool:

Merci !

Citation:

---

Envoyé par Bowen

Ah je n'ai pas dit que c'était une solution idéale non plus, je décris simplement ce que je sais.

---

Pas de soucis et c'est le but de ce forum, partager notre "savoir" :)