Aanmaak uniek veld door concatenatie van 2 velden in FM 6 Pr

[StefanHoste]

Hallo,

 

ik werk met FileMaker 6 Pro en ik heb een vraagje over een probleem waarmee ik geconfronteerd ben. Ik heb een layout met daarop drie velden en een button. Laat ons gemakkelijk stellen "veld A", "veld B", "veld C" en "button A".

 

Ik wil een nieuw record aanmaken en veld A en veld B worden ingevuld door middel van een keuzelijstje. Om dit record nu uniek te maken moet ik de waarde van veld A en de waarde van veld B concateneren en in veld C plaatsen (ik doe dit aan de hand van het script "SetField" dat via de button wordt aangeroepen). Zo wordt dit record uniek. Indien ik echter probeer om toch een nieuw record aan te maken (waarvan de waarde van dat veld al bestaat) laat FileMaker het toch toe om dit record te creëren.

 

Na lange tijd zoeken ben ik tot de constatatie gekomen dat hij enkel controleert wanneer je op de layout dit veld editeerbaar maakt. DIt is echter niet de bedoeling want de gebruikers mogen in geen geval dit unieke veld kunnen manipuleren.

 

Is er iemand die me kan helpen?

 

Met vriendelijke groeten,

 

Stefan Hoste

[AvD]

Er zijn vele mogelijkheden hier. Één ervan bestaat hierin dat je het unieke veld niet vult met een SetField maar met een AutoEnter by Calculation die pas in werking treedt wanneer de beide bronvelden not IsEmpty zijn. Dan zet je nog de optie Allow modification of value uit, en klaar is kees. Hiermee is je probleem natuurlijk niet opgelost, want de nieuwe record kan je toch al aanmaken met de lege bronvelden, zodat een validatie nooit zal werken: je moet immers eerst een record hebben! Je moet dus dieper in de truukjesdoos.

[Sanne]

Begrijp ik de situatie goed?

 

- Nieuw record (velden A en B en C leeg)

- gebruiker voert in velden A en B gegevens in

- gebruiker klikt op knop (met script)

- script zet inhoud van veld A en B gecombineerd in veld C

 

De voorwaarde is dat de inhoud van veld C uniek moet zijn.

 

Als dit de situatie is, dan kun je de controle in je script bouwen. Je hebt daarvoor een relatie nodig van dit bestand naar zichzelf op veld C (een interne relatie).

 

- Script zet gecombineerde waarde in veld C

- Script checkt of deze waarde uniek is, met behulp van de interne relatie en de count-functie (van het veld C via de interne relatie). De count moet namelijk het getal 1 opleveren (het record telt zichzelf)

- Is de count groter dan 1? Dan is het record niet uniek.

- Het script kan nu een melding geven en veld C weer leeg maken: met andere woorden, weigeren om veld C te vullen als het niet uniek is.

[StefanHoste]

Hartelijk bedankt,

 

door uw uitleg heb ik een oplossing gevonden , ik heb het volgende gedaan:

 

eerst moet ik er wel nog bij vermelden dat men bij het klikken op de knop ook naar een andere layout moet springen

 

het veld C aanmaken door combinatie A en B
if (Count gerelateerd veld C) > 0
    toon bericht ("Kan niet aanmaken want veld C moet uniek zijn, probeer opnieuw")
    verwijder record
    ga naar layout
else
    ga naar layout
end if

[Stef]

Die "COUNT>0" moet er helemaal niet in.

 

if (gerelateerd veld C

is genoeg.

 

Boolean denken!

 

HTH

Stef

[Sanne]

Beste mensen, even opletten als je met de count op een interne relatie wilt checken of het record uniek is. De isvalid-functie levert je namelijk ALTIJD 1 op als het veld gevuld is. De relatie is dan immers valide: het record ziet zichzelf. Het ziet ook eventueel andere records met dezelfde waarde, dus isvalid ALLEEN is niet voldoende om te checken of er maar 1 record is, met andere woorden: of de ingevoerde waarde uniek is.

 

Stef: boolean denken helpt je in dit geval niet: sterker nog, het brengt je op een dwaalspoor. Je zult echt een count moeten doen. En die count moet zijn: GROTER dan 1! Alleen op die manier kun je vaststellen of de waarde al eerder bestaat.

 

Stefan: de code zoals je die in je post laat zien, lijkt me onvoldoende. De count moet groter dan 1 zijn, omdat het record in principe zichzelf zal vinden: doe voordat je de test doet eerst een verlaat-record om zeker van de ingevoerde waarden te zijn.

Als de gecombineerde waarde al bestaat, dan het record weggooien lijkt mij wel erg rigoreus: waarom geef je de invoerder niet de mogelijkheid om de ingevoerde waarden te wijzigen.

[StefanHoste]

Sanne,

 

ik heb het zowel met > 1 als met > 0 geprobeerd. Bij > 1 geeft hij de foutmelding en bij > 0 laat hij de creatie van dat record gewoon toe, dus blijkbaar telt hij dat veld dat je juist hebt aangemaakt nog niet mee.

 

Het record bestaat maar uit 3 velden dat je zelf hoeft in te vullen, bovendien zijn dit allemaal keuzelijstjes, dus is dit niet zoveel werk om dit nogmaals in te voeren. En zo ben ik er ook zeker van dat alles zeker functioneert zonder fouten.

 

Nogmaals bedankt,

 

Stefan

[Dr_Flash]

Het record bestaat maar uit 3 velden dat je zelf hoeft in te vullen, bovendien zijn dit allemaal keuzelijstjes,

 

Maar dan kan je dus ook voor vast alle mogelijke combinaties van die twee velden 1 record aanmaken, en vervolgens simpelweg het creëren van nieuwe records verbieden

[StefanHoste]

Ik vrees van niet. Het ene veld kan ongeveer 32 waarden bevatten en het andere veld kan ongeveer 5000 waarden bevatten.

 

Nu hoor ik jullie al zeggen: een keuzelijstje voor 5000 records Maar dat zal ik later waarschijnlijk wel veranderen of anders oplossen want ik denk niet dat dit dmv een keuzelijstje erg handig zal zijn.

[AvD]

Ik vermoed hier een meer dan serieus analyse-probleem en een paar doodzondes tegen de normalisatie-regels ( ). Jammer dat onze Mexicaan niet hier is met zijn behangpapierrollen.

[Sanne]

Bij > 1 geeft hij de foutmelding en bij > 0 laat hij de creatie van dat record gewoon toe, dus blijkbaar telt hij dat veld dat je juist hebt aangemaakt nog niet mee.

 

Als je na het vullen van veld C GEEN exit-record doet, dan wordt de relatie anders ge-evalueerd dan wanneer je WEL de exit-record-stap zou doen.

 

Je hebt dus keuze, je kunt beide methoden gebruiken.

 

Mijn voorkeur zou hebben om na het zetten van het veld waarop je de relatie evalueert, een exit-record te doen.

 

[AvD]

Ik denk, Sanne, dat Stef het bedoelde ZONDER die IsValid.

[Sanne]

Als in:

[AvD]

Ja, zo doet ie dat.

[StefanHoste]

Inderdaad,

 

meneer AvD heeft gelijk. Ik had het echter eerst wel geprobeerd met die IsValid omdat ik dacht dat dit de volledige validatie zou checken (dus ook het uniek zijn). Maar blijkbaar werkte dit niet en was er geen functie zoals bvb IsUnique.

 

Zoals ik het nu heb werkt het, ik kan eventueel wel nog een Eit Record/Request doen en dan "> 0" nemen i.p.v. "> 1".

[StefanHoste]

Inderdaad,

 

meneer AvD heeft gelijk. Ik had het echter eerst wel geprobeerd met die IsValid omdat ik dacht dat dit de volledige validatie zou checken (dus ook het uniek zijn). Maar blijkbaar werkte dit niet en was er geen functie zoals bvb IsUnique.

 

Zoals ik het nu heb werkt het, ik kan eventueel wel nog een Eit Record/Request doen en dan "> 0" nemen i.p.v. "> 1".

[Dr_Flash]

Zo'n Uniquity Check, da's nou typisch iets wat je in FM7 Dev zou kunnen definiëren als een nieuwe functie

[StefanHoste]

Het zou willen lukken