mth_EffacerSelonID
Supprime un enregistrement et toutes les fiches qui lui sont liées selon les contraintes d'intégrité définies dans l'analyse. Gestion automatique de la transaction SQL. La suppression est irréversible.
📋 Description
mth_EffacerSelonID supprime l'enregistrement dont la clé primaire vaut nIDTuple, ainsi que les fiches qui lui sont liées via une cascade applicative orchestrée par le framework selon les contraintes définies dans l'analyse, et les traductions associées dans cshx2_traductions. La suppression est journalisée par défaut dans cshx2_trashcan (corbeille applicative — journal d'audit qui conserve les ID supprimés mais pas le contenu, donc la suppression reste irréversible).
Une fois la transaction validée, l'enregistrement et ses dépendances sont définitivement supprimés de la base. Pas de corbeille applicative, pas de reprise possible hors restauration de sauvegarde. À utiliser avec prudence — préférer un statut « archivé » ou « inactif » côté métier quand c'est pertinent.
La méthode gère sa transaction automatiquement :
• Si aucune transaction n'est active au moment de l'appel, elle en ouvre une qu'elle valide ou annule selon le résultat.
• Si une transaction parente est déjà active, elle ne touche pas à la transaction et c'est l'appelant qui en est responsable (commit ou rollback).
Détails et exemples dans la page ORM_Transactions.
Si nIDTuple ≤ 0, la méthode retourne immédiatement (Vrai, 0, "") sans toucher à la base. C'est un garde-fou intentionnel contre les suppressions massives accidentelles (un ID non chargé vaut 0 par défaut).
Attention : le retour étant un succès apparent, l'appelant qui passe un ID invalide ne sera pas averti que rien ne s'est passé. Si la confirmation de suppression est critique côté métier, valider nIDTuple > 0 avant l'appel.
🔑 Signature
LOCAL nIDTuple est un entier
) : (booléen, entier, chaîne)
| Élément | Valeur |
|---|---|
| Visibilité | PUBLIQUE |
Paramètre
| Paramètre | Type | Rôle |
|---|---|---|
nIDTuple | entier | Valeur de la clé primaire de l'enregistrement à supprimer. Si ≤ 0, la méthode retourne sans rien faire (voir §01). |
🧹 État de l'objet après suppression
En cas de suppression réussie (bProcessing = Vrai), l'objet courant est réinitialisé : tous les membres mappés repassent à leurs valeurs par défaut, comme après un appel à mth_RAZ. Cela évite que l'objet conserve en mémoire des données qui n'existent plus en base.
La propriété p_bRecordDeleted (alias français : p_bEnregistrementSupprimé) est ensuite positionnée à Vrai pour signaler explicitement que l'instance représente un enregistrement supprimé. Ce drapeau est exploité par les méthodes d'agrégat (mth_SommeValeurs, mth_ValeurMoyenne, mth_ValeurMaximale, mth_ValeurMinimale, mth_ValeursDistinctes, mth_Regroupement) pour exclure les éléments supprimés du calcul.
En cas d'échec, l'objet est laissé en l'état — les valeurs précédemment chargées restent disponibles pour diagnostic ou retry.
🔍 Voir ce qui se passe — mode verbose
Comme la méthode orchestre plusieurs requêtes SQL en une seule opération (verrouillage, suppression principale, cascade applicative, traductions, archivage corbeille, validation transaction), le mode verbose est l'outil de diagnostic privilégié pour visualiser ce qui est réellement exécuté.
Trace produite (extrait illustratif) — chaque ligne préfixée d'un emoji selon l'opération :
Détails complets : ORM_VerboseMode.
📤 Valeur de retour
Triplet standard ORM (bProcessing, nErrorCode, sErrorMessage) :
| Retour | Condition |
|---|---|
(Vrai, 0, "") | La suppression s'est bien déroulée — ou nIDTuple ≤ 0 (no-op silencieux, voir §01). |
(Faux, <code>, sMsg) | Échec de la suppression — voir la section ⚠️ Gestion des erreurs. |
⚠️ Gestion des erreurs
| Code | Constante | Condition |
|---|---|---|
-23099 | ERR_ORM_DELETE_VERROUILLE | L'enregistrement à supprimer est verrouillé par un autre poste / utilisateur. Le message d'erreur contient l'IP du poste détenteur du verrou. |
-23098 | ERR_ORM_DELETE_PROVIDER | Provider SQL non géré pour la suppression de l'enregistrement principal. |
-23097 | ERR_ORM_DELETE_TRAD_VERROUILLE | Une traduction associée à l'enregistrement (dans cshx2_traductions) est verrouillée par un autre poste / utilisateur. |
-23096 | ERR_ORM_DELETE_TRAD_PROVIDER | Provider SQL non géré pour la suppression des traductions. |
-999 | ERR_SQL_INVALID_REQUEST | Erreur SQL générique (contrainte d'intégrité bloquant la suppression, syntaxe, etc.). Le détail est dans sErrorMessage. |
Le code ERR_ORM_DELETE_VERROUILLE ne correspond pas à un verrou SQL classique mais au verrou applicatif géré par ORM_CSHX2 via les colonnes framework SQL_LOCKED et SQL_IP_USER. Si un autre poste a verrouillé l'enregistrement (via mth_LockSelonID par exemple) sans l'avoir relâché, la suppression échoue.
Si la suppression viole une contrainte de clé étrangère qui ne définit pas ON DELETE CASCADE, le moteur SQL rejette l'opération. L'erreur remonte alors via ERR_SQL_INVALID_REQUEST (-999) avec le message d'origine du provider. La transaction est annulée automatiquement.
💡 Exemples
Mode 1 — suppression isolée (transaction auto-gérée)
Mode 2 — suppression dans une transaction parente (lot atomique)
Quand plusieurs opérations doivent réussir ou échouer ensemble, ouvrir une transaction côté appelant. La méthode détectera la transaction parente et n'y touchera pas.
Mode 3 — validation préalable côté appelant
Pour éviter le no-op silencieux sur nIDTuple ≤ 0, valider l'ID avant l'appel.