Dans les écrans paramétrables, Mercator permet l'utilisation de listes déroulantes (ComboBox). Ces listes présentent des valeurs possibles
- soit des éléments proposés par Mecator
- soit des éléments personnalisés provenant d'une liste fixe
- soit des éléments provenant d'une requête SQL personnalisée.
La problématique est que ces valeurs possibles peuvent changer au gré de la vie de Mercator. Il est dès lors possible qu'une colonne associée à une liste déroulante, contienne des valeurs qui ne sont plus reprises dans cette liste déroulante. Cette situation est problématique, car dans ce cas, le déroulant affiche une valeur vide alors qu'en définitive, la base de données contient une valeur périmée.
Via les outils avancés, "Base de Données SQL / Vérifier Combobox", Mercator propose un outil qui permet de lister ces incohérences et d'y remédier en remplaçant les valeurs périmées par "vide" ou "zéro". Pour que cette fonctionnalité soit accessible, il faut que l'écran actif de Mercator soit d'un type de fenêtre pour lequel on souhaite effectuer le contrôle. (Le contrôle n'est pas limité à la fiche en cours).
Le cas échéant, Mercator produit un rapport d'erreur montrant sur chaque ligne, la clé primaire de l'enregistrement concerné, suivi du nom de la colonne et de sa valeur périmée. Dans un second temps, Mercator propose un script dans l'éditeur de requêtes SQL afin de remédier à ces constatations.
Mercator donne cet avertissement : "Il est possible que certaines corrections suggérées ne soient pas pertinentes. Ceci en fonction de votre paramétrage.". En effet, si par exemple, un système a été mis en place pour que les valeurs présentées soient modifiées dynamiquement en fonction de l'enregistrement sur lequel on se trouve, Mercator n'est pas en mesure de détecter correctement les erreurs et de proposer une correction.
A ce stade du développement, cette fonctionnalité est limitée aux signalétiques de Mercator.
Comment prévenir de telles incohérences ?
Des contraintes peuvent être placées sur la base de données SQL afin d'empêcher les incohérences décrites ci-dessus. Mercator peut apporter une aide substantielle quant à cette mise en place. Cela se fait au départ du paramétrage d'écran, via le menu contextuel sur un combobox :
La fonctionnalité décrite ici n'est disponible que pour les déroulants dont la liste des éléments n'est pas prédéterminée par Mercator. (Sinon, le message "Impossible d'ajouter cette contrainte !" est donné à l'utilisateur.)
L'ajout d'une contrainte se fait toujours via l'éditeur de code SQL. Le script est proposé. Il peut toujours être adapté avant son exécution.
Si les éléments du déroulant proviennent d'une liste fixe, alors Mercator propose une contrainte basée sur "in" , telle que
ALTER TABLE CLI WITH CHECK ADD CONSTRAINT CHECK_CLI_C_COMPANY CHECK (C_COMPANY in ('','INEO','ADEO'))En cas de changement apporté dans la liste des valeurs possibles, il sera nécessaire d'adapter la contrainte en exécutant à nouveau "Ajouter Contrainte".
Si les éléments du déroulant proviennent d'une requête SQL, alors Mercator va proposer la création d'une fonction SQL et l'utiliser dans la contrainte. La fonction SQL est construite par Mercator de façon agnostique, çàd sans rien reconnaître dans cette requête SQL (qui pourrait être l'appel d'une procédure stockée par exemple). Dans bien des cas donc, le code de la fonction SQL peut être simplifié (retrait de l'imbrication de requête).
CREATE FUNCTION dbo.COMBOCHECK_CLI_C_COMPANY (@p varchar(250)) RETURNS bit
AS
BEGIN
declare @r bit
set @r=0
if exists(select * from (select nom from COMPANIES) tcombo where tcombo.nom=@p)
set @r=1
return @r
END
GO
ALTER TABLE CLI WITH CHECK ADD CONSTRAINT CHECK_CLI_C_COMPANY CHECK (C_COMPANY='' or dbo.COMBOCHECK_CLI_C_COMPANY(C_COMPANY)=1)
Concernant ce dernier type de contrainte, si tous les enregistrements doivent obligatoirement recevoir une valeur provenant de la table personnalisée (COMPANIES dans notre exemple), alors la mise en place d'une contrainte de clé étrangère est préférable (foreign key).
Lors de l'ajout de la contrainte, si celle-ci existe déjà, ou si la fonction SQL est déjà présente, Mercator proposera, dans son script SQL, le retrait de ces éléments.
Concernant les rayons / familles / sous-familles : voir cette page
Pourquoi Mercator n'impose-t-il pas cette vérification par défaut sur la base de données ?
L'équipe de programmation de Mercator a évalué ceci et donné cette réponse :
- Le haut degré de personnalisation de Mercator est tel qu'il n'est pas possible de généraliser un principe. Les valeurs dont question ci-dessus sont-elles stratégiques à ce point qu'il faille absolument les protéger par des mécanismes d'intégrité de base de données ou pas ?
- En informatique de gestion, chaque chose a un coût. L'abus de contraintes aussi. Nous savons que l'ajout systématique de contraintes aura un impact indéniable sur les chargements, par exemple par import Excel, de fichiers contenant plusieurs dizaines de milliers d'articles (opération très fréquente chez certains utilisateurs).