In de configureerbare schermen staat Mercator het gebruik van vervolgkeuzelijsten (ComboBox) toe. Deze lijsten tonen mogelijke waarden
- hetzij elementen aangeboden door Mercator
- hetzij gepersonaliseerde items uit een vaste lijst
- hetzij elementen uit een aangepaste SQL-query.
Het probleem is dat deze mogelijke waarden kunnen veranderen tijdens de levensduur van Mercator. Het is daarom mogelijk dat een kolom die is gekoppeld aan een vervolgkeuzelijst waarden bevat die niet langer in deze vervolgkeuzelijst staan. Dit is problematisch, omdat in dit geval de vervolgkeuzelijst een lege waarde weergeeft wanneer de database uiteindelijk een verouderde waarde bevat.
Via de geavanceerde tools, "SQL Database / Check Combobox", biedt Mercator een tool aan die het mogelijk maakt om deze inconsistenties op te lijsten en te verhelpen door de verouderde waarden te vervangen door "leeg" of "nul". Om deze functionaliteit toegankelijk te maken, moet het actieve Mercator-scherm van een type venster zijn waarvoor u de controle wilt uitvoeren. (De controle is niet beperkt tot de huidige fiche).
Indien van toepassing produceert Mercator een foutrapport met op elke rij de primaire sleutel van het betreffende record, gevolgd door de naam van de kolom en zijn vervallen waarde. Ten tweede biedt Mercator een script in de SQL-queryeditor om deze bevindingen te verhelpen.
Mercator geeft deze waarschuwing: "Sommige voorgestelde oplossingen zijn mogelijk niet relevant. Dit hangt af van uw instellingen." Als er bijvoorbeeld een systeem is opgezet zodat de gepresenteerde waarden dynamisch worden gewijzigd volgens het record waarop we ons bevinden, is Mercator niet in staat om fouten correct op te sporen en een voorstel te doen voor een correctie.
In dit stadium van ontwikkeling is deze functionaliteit beperkt tot de bestanden van Mercator.
Hoe kunnen dergelijke inconsistenties worden voorkomen ?
Er kunnen beperkingen worden gesteld aan de SQL-database om de hierboven beschreven inconsistenties te voorkomen. Mercator kan bij deze implementatie substantieel helpen. Dit doe je aan het begin van de scherminstellingen, via het contextmenu op een combobox :
De hier beschreven functionaliteit is alleen beschikbaar voor vervolgkeuzemenu's waarvan de lijst met items niet vooraf is bepaald door Mercator. (Anders wordt het bericht "Kan deze beperking niet toevoegen!" aan de gebruiker gegeven.)
Het toevoegen van een beperking gebeurt altijd via de SQL-code-editor. Het script wordt aangeboden. Het kan altijd worden aangepast voordat het wordt uitgevoerd.
Als de vervolgkeuzelijsten uit een vaste lijst komen, stelt Mercator een beperking voor op basis van "in", zoals
ALTER TABLE CLI WITH CHECK ADD CONSTRAINT CHECK_CLI_C_COMPANY CHECK (C_COMPANY in ('','INEO','ADEO'))In het geval dat er een wijziging is aangebracht in de lijst met mogelijke waarden, zal het nodig zijn om de beperking aan te passen door opnieuw "Add Constraint" uit te voeren.
Als de vervolgkeuzelijsten afkomstig zijn van een SQL-query, stelt Mercator voor om een SQL-functie te maken en deze in de beperking te gebruiken. De SQL-functie is door Mercator op een agnostische manier gebouwd, d.w.z. zonder iets in deze SQL-query te herkennen (wat bijvoorbeeld de aanroep van een opgeslagen procedure kan zijn). In veel gevallen kan daarom de code van de SQL-functie worden vereenvoudigd (verwijdering van query-nesting).
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)
Wat betreft dit laatste type beperking, als alle records verplicht een waarde moeten ontvangen die afkomstig is van de gepersonaliseerde tabel (BEDRIJVEN in ons voorbeeld), dan heeft de implementatie van een externe sleutelbeperking de voorkeur (foreign key).
Bij het toevoegen van de beperking, als deze al bestaat, of als de SQL-functie al aanwezig is, zal Mercator in zijn SQL-script voorstellen om deze elementen te verwijderen.
Betreffende Rayons/Families/Subfamilies: zie deze pagina
Waarom legt Mercator deze controle niet standaard op aan de database ?
Het programmeerteam van Mercator evalueerde dit en gaf het volgende antwoord :
- De hoge mate van personalisatie van Mercator is zodanig dat het niet mogelijk is om een principe te generaliseren. Zijn de hierboven besproken waarden zo strategisch dat ze absoluut moeten worden beschermd door mechanismen voor database-integriteit of niet ?
- Bij het beheer van informatica heeft alles een prijs. Ook het misbruik van beperkingen. We weten dat het systematisch toevoegen van beperkingen een onmiskenbare impact zal hebben op het laden, bijvoorbeeld door Excel te importeren, van bestanden met enkele tienduizenden artikelen (zeer frequent gebruik voor sommige gebruikers).