data uit emerdere tables in 1 portal

[Guido]

Beste,

 

ben nu al een tijdje bezig met filemaker, maar stuit dit keer op het volgende probleem:

ik wil een zoekfunctie maken met items van klanten. Een klant heeft bijvoorbeeld een 2 offertes en bijv. 5 orders. Deze orders en offertes staan natuurlijk in verschillende tables (en wel: orders en offertes) Nu wil ik bij een zoekpagina in het portaal zowel de 2 orders als de offertes zien. Ik heb eea gelezen over join tables, maar het lukt me niet.

 

Het doel, misschien ook wel interessant:

ik wil dus in die portaal met een script maken dat als je bij die klant op bijvoorbeeld order 2 drukt in het portaal, haalt hij die gegevens op en laat hij die zien zodat je snel per klant zijn historie kan zien

 

Weet iemand de oplossing?

 

Gr Guido

[AvD]

Probeer het simpel en efficiënt te houden: zet twee portalen naast of boven elkaar. Meer is echt niet nodig...

Edited September 25, 2006 by Guest

[Guido]

Probeer het simpel en efficiënt te houden: zet twee portalen naast of boven elkaar. Meer is echt niet nodig...

 

hey,

 

dat vind ikzelf niet zo goed te overzien. Op de manier die ik wil kan ik bijvoorbeeld ook een andere functie gaan gebruiken. namelijk alle records van alle items in 1 portaal zetten welke "vandaag" gewijzigd zijn, dan kan degene die dat moet controleren dat zeer overzichelijk per dag zien ipv in 5 of 6 portalen te kijken (aangemaakte orders, facturen, klanten, calculaties, offertes, correspondentie, etc)

[Guido]

niemand die het weet?

[Rony Rabijns]

Wat je vraagt kan indien je bij de aanmaak van een order, ook een record (automatisch) aanmaakt in de "verzamel"-tabel. Hetzelfde geldt voor de facturen en alle andere zaken die je wil koppelen aan de klanten en later wil kunnen opvragen via dat portaal.

 

Maar ... ik volg AvD en vind je idee niet goed.

[Johnny]

Het is heel goed mogelijk om in 1 portaal meerdere tabellen te tonen op basis van een relatie waarvan je de key variabel maakt. Via buttons verander je de key en daarmee de inhoud van het portaal.

[Rony Rabijns]

Het is heel goed mogelijk om in 1 portaal meerdere tabellen te tonen op basis van een relatie waarvan je de key variabel maakt.

 

Laten zien zou ik zeggen ...

[AvD]

Mag ik erbij zijn als dat getoond wordt?

[JeanWM]

Ik denk dat Johnny een woord vergeten is....

 

...zodat enkelen (ik ook! ) iets anders in gedachte hebben....

 

Maar je weet maar nooit....zo André, schuif een beetje op, 'kwil er ook bij op deersterij....

[Johnny]

Oeps, daar vallen de zwaargewichten over me heen want ik heb iets geroepen dat niet kan, maar ik had inderdaad iets anders in gedachten. In 1 van mijn solutions kan de gebruiker de portaalinhoud wisselen door buttons te klikken: het portaal laat dan respectievelijk offertes, orderbevestigingen en facturen per klant zien. Dat effect had ik voor ogen toen ik de probleemstelling zag. Vergeten was ik hoe dat was gemaakt. Ik dacht vanuit drie tabellen, maar wat blijkt: de gegevens zijn allemaal in 1 tabel gestopt. Tsja, en dan is het simpel om via wisseling van de ID (een global met wisselende inhoud) andere gegevens in het portaal te toveren.

 

Is dat trouwens ook niet de oplossing voor het gestelde probleem? Stop de gegevens in 1 tabel en tover ze in het portaal met een wisselende ID. Het is niet persé nodig voor elk item een aparte tabel aan te maken. Als ze functioneel zijn in 1 tabel kan dat het nodige gemak opleveren.

[Rony Rabijns]

Oeps, daar vallen de zwaargewichten over me heen want ik heb iets geroepen dat niet kan, maar ik had inderdaad iets anders in gedachten.

 

 

Oooooohhhhhh jammer.

Einde voorstelling. Ik keek er zo naar uit. :-D

[JeanWM]

Positie 2 tot 6 uit het derde woord van het onderwerp.....

[Rony Rabijns]

Positie 2 tot 6 uit het derde woord van het onderwerp.....

doemme

[AvD]

Stop de gegevens in 1 tabel en tover ze in het portaal met een wisselende ID. Het is niet persé nodig voor elk item een aparte tabel aan te maken. Als ze functioneel zijn in 1 tabel kan dat het nodige gemak opleveren.

Je gaat hier erg zwaar in tegen de normalisatieregels:

"Stop de gegevens in 1 tabel":

Dit kan écht niet, als je die regels volgt, tenzij "de data functioneel (ik hoop dat je bedoelt wat ik hoop) zijn in één tabel". In dit laatste geval was het opsplitsen in meer dan één tabel een al even zware inbreuk op de regels.

Ik vrees dat we tot slechts één enkele conclusie kunnen komen: het pseudo-confort van een user interface wordt hier boven de normalisatieregels gesteld. Dat is NIET goed.

[Guido]

Stop de gegevens in 1 tabel en tover ze in het portaal met een wisselende ID. Het is niet persé nodig voor elk item een aparte tabel aan te maken. Als ze functioneel zijn in 1 tabel kan dat het nodige gemak opleveren.

Je gaat hier erg zwaar in tegen de normalisatieregels:

"Stop de gegevens in 1 tabel":

Dit kan écht niet, als je die regels volgt, tenzij "de data functioneel (ik hoop dat je bedoelt wat ik hoop) zijn in één tabel". In dit laatste geval was het opsplitsen in meer dan één tabel een al even zware inbreuk op de regels.

Ik vrees dat we tot slechts één enkele conclusie kunnen komen: het pseudo-confort van een user interface wordt hier boven de normalisatieregels gesteld. Dat is NIET goed.

 

Klopt, dan gaat het interdaad niet. Het idee was dat ik met een klik op de het portaal "facturen" bijvoorbeeld de factuurregels in een apart portaal kan zien. Dat is allemaal makkelijk realiseerbaar, maar nu blijkt dus dat je voor EN factuurregels, EN offerteregels, etc een apart portaal moet maken en dan over elkaar heenzetten oid. Maar dan kan je weer niet scrollen tenzij...? het volle portaal actief is.... hoe ga ik dat maken als er dan weer een keer naast wordt geklikt...

 

Ik heb even gezocht op zo'n hierachy ding, dan zouden de factuurregels in hetzelfde portaal komen te staan als factuur, maar wel per factuur geresumeerd, dat is ook wel mooi, maar volgens mij veel te ingewikkeld. Iemand ideeen daarvoor?

[Koen Van Hulle]

Ik zou het zo sterk niet willen uitdrukken, André. Liever een slechte data structuur, met een toepassing die doet wat het moet doen en de gebruiker helpt, dan een zeer strict genormaliseerde data structuur, met een interface waar niemand wil en kan meewerken. Het hangt er bovendien ook vanaf wie het bouwt. De eindgebruiker of een professioneel consultant.

 

Om op de vraag te antwoorden. Je doet inderdaad het best wat Ronny voorstelt: een schaduwtabel.

 

FileMaker heeft jammergenoeg niet zoiets als views en tijdelijke virtuele tabellen. Je kijkt altijd rechtstreeks naar je data.

 

Koen

[AvD]

Liever een slechte data structuur, met een toepassing die doet wat het moet doen en de gebruiker helpt, dan een zeer strict genormaliseerde data structuur, met een interface waar niemand wil en kan meewerken.

Dit is een zeer fundamenteel standpunt, en van iemand met jouw autoriteit kunnen we niet anders dan dat aanvaarden. Maar dat zet dan wel de normalisatieregels op losse schroeven. Van regels worden het dan aanbevelingen... Mij is altijd gezegd dat je - indien je afweek van die regels - vroeg of laat problemen zou krijgen.

[Guido]

Ik zou het zo sterk niet willen uitdrukken, André. Liever een slechte data structuur, met een toepassing die doet wat het moet doen en de gebruiker helpt, dan een zeer strict genormaliseerde data structuur, met een interface waar niemand wil en kan meewerken. Het hangt er bovendien ook vanaf wie het bouwt. De eindgebruiker of een professioneel consultant.

 

Om op de vraag te antwoorden. Je doet inderdaad het best wat Ronny voorstelt: een schaduwtabel.

 

FileMaker heeft jammergenoeg niet zoiets als views en tijdelijke virtuele tabellen. Je kijkt altijd rechtstreeks naar je data.

 

Koen

 

Beste koen,

 

bedankt voor je antwoord, ik heb er al even na zitten kijken toen rony het zei. Echter, hoe moet je een schaduwtabel maken? ik maak de regels vanuit een portal aan, dan kan je toch niet zomaar schaduwen?

[Koen Van Hulle]

Nee, inderdaad. Je zal het moeten scripten. Dus met creërende relaties zal het niet zomaar lukken.

 

André, ik volg je stelling. Vroeg of laat kan je problemen krijgen. Voor de één kan dat dramatisch zijn (en veel werk op dit ogenblik), bij een ander valt het allemaal wel mee. Het is een beetje in het juiste perspectief plaatsen: Wat is het belang van je toepassing? Wat is de levensduur? ...

 

Als pro's vind ik wel dat we aan ons zelf en de klant verplicht zijn, goed na te denken over de data structuur. Daarvoor worden we immers betaald.

 

Maar de fierheid en trots waarmee een eindgebruiker toont wat hij gemaakt heeft, en hoe het zichzelf of zijn organisatie heeft opgebracht, is onbetaalbaar...

 

Koen

[Guido]

gek dat die vraag nog nooit eerder gekomen is eigenlijk, ik zou het enorm handig vinden als je gewoon een Y-relatie zou kunnen maken ipv 1:1

 

enfin, ik heb het nu gefixed met over elkaar staande portals. In tab 1 selecteer je welk factuur je wilt zien, in tab 2 de offerte, 3 de calculaties van die klant, en als je in dat portaal klikt op een record, laat hij met een zeer eenvoudig scriptje zien welke regels bij die order horen in een ander portaal. Dit andere portaal is over elkaar geplaatst (dus offerteregels onder orderregels onder calculatieregels), en dit werkt best leuk, maar tis natuurlijk geen mooie oplossing.

 

Hoe kan je dan scrollen, want een portaal over een ander portaal kan helemaal niet scrollen als in de onderste meer dan het gekozen aantal portaalrijen aan records staan? Welnu, dat is dus op te lossen met een Go to field "z" scriptje afhankelijk welk ID er groter dan 0 is (factuurID, calcID, etc)

 

wie heeft er een mooiere oplossing?