Portaal met resultaten

[Rony Rabijns]

Ik heb één tabel met één veld, gevuld met data die niet uniek is.

Op de layout waarop een willekeurig record getoond wordt uit die tabel, moet ook een portaal staan, met daarin enkel en alleen de unieke waarden van dat veld uit alle records.

 

Bijvoorbeeld:

- tabel met 6 records

- het veld "data" bevat de waarden "1","2","2","3","3","1".

- het portaal mag dan enkel de waarden "1", "2" en "3" bevatten.

 

Welk is de meest aangegeven methode om dit (dynamisch) te bekomen?

[hiker]

Een invoerlijst zou dit in een keer oplossen, dat is geen optie?

[fmwebshop]

Of met een scriptje.

 

Vr groet

Harry

Naamloos.fp7

[Rony Rabijns]

@Hiker:

Het moet een portaal zijn. De bedoeling is om met die unieke waardes te gaan werken als zouden het records zijn.

 

@Harry:

Zo deed ik het tot nu ook, maar dat is niet dynamisch genoeg naar mijn zin. Met de import die je voorstelt, moet je nog altijd handmatig een script starten, of eventueel via een plugin triggeren.

Ik wil eigenlijk een relationele oplossing vinden. Op die manier ben ik totaal onafhankelijk van scripts, plugins en data.

 

Ik ben er nu toch al een tijdje mee bezig, en het is een flinke uitdaging om een relationele oplossing te vinden. Maar ik ben er van overtuigd dat ze d'er is.

[pjotter]

Rony, hoe worden de velden gevuld?

Heel simpel zeg ik: een extra tabel met velden die komen uit de master tabel die geen unieke velden heeft. Vervolgens de tabel met de unieke nummers gebruiken in je database? Ik weet natuurlijk niet of je met die schaduw tabel kunt werken?

[Rony Rabijns]

Dag pjotter,

De velden worden gevuld vanuit een import (80%) en handmatig (20%).

 

Ik kan met een schaduwtabel werken, zo deed ik het ook al. Dat is de oplossing zoals Harry ze ook voorstelde. Maar dat wil ik niet. De unieke waardes moeten on-the-fly getoond worden.

Als ik in de tabel een record bijmaak met een uniek gegeven, wil ik dat onmiddellijk zien in het portaal. Bij voorkeur niet via een script (cfr import), maar relationeel.

[Jeroen Aarts]

Haha wat een uitdaging! In bijlage een oplossing waarvoor wel een extra calc veld vereist is.

 

Cheers!

 

Jeroen

Uniek.fp7

[fmwebshop]

Mijn bescheiden poging

 

Vr groet

Harry

Naamloos.fp7

[Rony Rabijns]

Haha wat een uitdaging!

Lach je me nu uit?

[Rony Rabijns]

Mijn bescheiden poging

 

Harry,

De bedoeling en richting zijn zeker goed, maar er staan nog wat te veel records in het portaal.

De oplossing van Jeroen is wat ik zocht. Bedankt.

[Jeroen Aarts]

Lach je me nu uit?

 

Neenee, helemaal niet! Het zal mijn jeugdig enthousiasme geweest zijn. Het was inderdaad een hersenbreker...

 

Jeroen

[Rony Rabijns]

Lach je me nu uit?

Neenee, helemaal niet! Het zal mijn jeugdig enthousiasme geweest zijn. Het was inderdaad een hersenbreker...

 

Oh, dan is het goed.

 

Misschien is het een goed idee dat je hier een korte beschrijving geeft hoe je oplossing werkt en wat de gebruikte techniek is? Zo heeft iedereen er later ook nog iets aan.

[ReneBr]

Hallo Rony,

 

Is dit wat je zoekt? Ik gebruik dit als zoekfunctie maar volgens mij kun jij dit ook gebruiken. help-1.fp7

 

Met dank aan Andries.

 

Vr.Gr.

 

René

[fmwebshop]

Chapeau voor de meester

 

Harry

[Rony Rabijns]

Is dit wat je zoekt? Ik gebruik dit als zoekfunctie maar volgens mij kun jij dit ook gebruiken.

 

Dag René,

Dit zocht ik niet. Wat jij voorstelt is een portaalfiltering.

De oplossing van Jeroen hierboven voldoet.

[Jeroen Aarts]

Misschien is het een goed idee dat je hier een korte beschrijving geeft hoe je oplossing werkt en wat de gebruikte techniek is? Zo heeft iedereen er later ook nog iets aan.

 

Inderdaad, hieronder wat meer info. De denkpiste die ik volgde, was hoe je verschillende records met een zelfde waarde, naar 1 en slechts 1 record met deze waarde kon doen verwijzen. Op deze manier toon je enkel die records met een unieke waarde. Je moet erin slagen om op de een of andere manier een veel-op-één relatie te creëren.

 

Dit klinkt nogal abstract, maar volg even mee:

- Allereerst creëren we een zogenaamde self-join, waarbij we de tabel met waarden aan zichzelf linken. In de relationship graph, gaat het om 'Uniek 2' en 'Uniek 3'

- De link wordt gelegd tussen het veld data in 'Uniek 2' en hetzelfde veld data in 'Uniek 3', wat dus niet-unieke waarden bevat over de records heen (bv 2 komt meerdere keren voor)

- Een record aan de linkerkant (Uniek 2), heeft een match met mogelijk meerdere records met dezelfde waarde aan de rechterkant (Uniek 3)

- Je creëert nu ahw een vehikel om voor verschillende records met dezelfde waarde, toch iets te maken, dat naar slechts 1 record verwijst. Dit doe je met het veld 'cFirstID'. cFirstID verwijst naar de ID (unieke identificatie record) van de eerst matchende record aan de rechterzijde. Belangrijk is dat je begrijpt dat, van de linkerkant uit bekeken, records met dezelfde waarden, alle dezelfde waarde zullen hebben in cFirstID, nl. de record van de eerst aangemaakte record met de betreffende waarde. Klinkt raar, want aan de linkerkant bevatten nu records met een zelfde waarde in data, nu ook een gemeenschappelijke waarde in cFirstID. Maar het gaat erom dat de ID - per definitie - elk record wél uniek identificeert aan de rechterkant, en data niet. Beeldend uitgedrukt, maak je een soort bruggetje.

- Om nu in de portal lijnen te tonen met een unieke waarde, volstaat het om aan de lnkerkant (Uniek 4) het veld cFirstID te matchen met ID (Uniek 5). Dit betekent dan dat aande linkerkant, verschillende records met een zelfde waarde, alle naar het eerste records met die waarde verwijzen in 'Uniek 5'. Je creëert dus op een kunstmatige manier een veel-op-een relatie.

 

Hopelijk verduidelijkt dit een en ander. In bijlage een kleine update, want in de relatie van 'Uniek 4' naar 'Uniek 5', is de extra match van data naar data in feite niet nodig

 

 

- Jeroen

Uniek.fp7

[Rony Rabijns]

Hier heeft iedereen iets aan. Bedankt.

[Roger]

Wat een schitterende oplossing is dit!! Ongelooflijk.

 

Zelf was ik hier ook naar op zoek in mijn geposte vraag van 18 nov. jl., maar vermoedde dat dit onmogelijk was. Ik loste het op met een extra tabel (in de app. die ik aan het bouwen ben een heel aantal extra tabellen zelfs) en een – automatisch geactiveerd – script. Maar dit is zoveel beter, 100% solide, perfect gewoon.

[Roger]

Enthousiast deze oplossing toegepast hebbende (9 portalen met (berekende) resultaten op 1 layout en een tabel met (slechts) 6000 records) moet ik toch een kanttekening maken: De snelheid. Deze zakt terug naar een onprettig niveau naarmate de tabel zich verder vult met records. Naar de betreffende layout navigeren en voordat de portalen dan zijn opgebouwd en je weer eens wat kunt gaan doen ben je toch al gauw 20 a 30 seconden verder. Verlaat je de layout en kom je (na niet al te lang) terug dan staat alles er wel meteen. Maar duurt het daarentegen wat langer voor je weer eens terugkeert, dan moet de inhoud van de portalen weer worden berekend en kun je weer snel even op en neer naar de koffieautomaat. Als de layout eenmaal is opgebouwd werkt het super, maar telkens tegen die wachttijd aanlopen wordt toch snel vervelend.

[Jeroen Aarts]

Inderdaad, dat viel wel te verwachten. Voor grotere recordsets zou ik dit zelf nooit doen, en naar een oplossing met scripts en een tijdelijke tabel bv. gaan.

 

Jeroen