getsummary veld in portaal

[geenbericht]

HOi, allen

 

Ik denk stel maar een vraag, want heb nu al lang op zitten broeden.

 

Als ik een getSummary veld plaats in een portaal geeft deze niets weer.

Hoe komt dat zo?

 

moeder tabel --> kindertabel

id..................--> SoortIDfk

.......................... prijs

..........................GetSummary ( SumPrijs ; SoortIDfk )

 

 

 

groet, Maurice[/b]

[AvD]

Ik heb dat zelf nog nooit gedaan en ik vermoed dat dat te maken heeft met schroomvallig respect voor het werkingsprincipe van een portaal; we kunnen toch ook geen portalen laten zien in een portaal. Met een GetSummary vraag je datatechnisch gezien hetzelfde. Het lijkt me logisch dat dat in FileMaker niet werkt.

Het komt me voor dat we iedereen moeten waarschuwen tegen opdrachtgevers die langs de ene kant verwachten dat we een perfecte data-analyse maken, maar dat we anderzijds ook alles op één enkel scherm kunnen tonen...

[geenbericht]

het werkingsprincipe van een portaal laat het dus niet toe

gegroepeerde data te tonen.

Zeg ik dat juist?

[AvD]

Op gevaar af me onduidelijk uit te drukken en met het strikte voorbehoud dat ik het niet geprobeerd heb: het principe van een portal is juist wél van gegroepeerde data te tonen, maar dan enkel van het eerste niveau onder dat van de actuele tabel. Vanuit een parent zie je dus de children maar niet de virtuele data over die children (zoals bijvoorbeeld een totaal of een gemiddelde). Maar die kan je wel berekenen in de hoofdtabel (degene die ik hierboven de actuele heb genoemd). Je zet die dan netjes onder de relevante velden die in de portaal staan. Probeer het maar eens: definieer bijvoorbeeld in je hoofdtabel een calculatieveld dat het aantal telt in een portaal, bijvoorbeeld een factuurdatum. Als er 8 facturen staan, en op elke factuur is de datum ingevuld, dan zal dat calculatieveld met die Count-functie netjes 8 als resultaat geven. En zo kan je natuurlijk ook werken met de Sum-functie, en dan zit je waar je moet zijn. Denk ik toch...

[geenbericht]

Ik denk dat je begrijp. Nu hoop ik niet vijf knuppels in het hoendehok te gooien maar... het is wel iets waar ik lang over denk:

 

nl.

in SQL creer je mbv 2 regels queries te trekken een view met gegroepeerde data, zonder extra velden of data aan te maken.

 

ps fm kan ook queries trekken toch?

[burggraaf]

in SQL creer je mbv 2 regels queries te trekken een view met gegroepeerde data, zonder extra velden of data aan te maken. ps fm kan ook queries trekken toch?

 

Statement van het jaar :"FMP is geen SQL en SQL is geen FMP"

 

Ik denk dat AvD heel duidelijk heeft uitgelegd hoe het werkt binnen FMP...

[AvD]

Dat zou anders niet slecht zijn: dan hadden we maar één programma nodig, we konden er maar één kopen en we konden maar over één klagen

[Koen Van Hulle]

in SQL creer je mbv 2 regels queries te trekken een view met gegroepeerde data, zonder extra velden of data aan te maken.

 

ps fm kan ook queries trekken toch?

 

Gelijk heb je. In SQL heb je iets als views, en die gedragen zich op zijn beurt weer als een tabel. Je kan dus makkelijk een interface op een view maken en doorheen de records van de view bladeren bijvoorbeeld.

 

In FileMaker heb je dat principe niet. Je kijkt altijd rechtstreeks naar de echte data. Je kan gerelateerde data filteren door "queries" te trekken. Dit zijn die uitgebreide opties bij een relatie. Het principe in FileMaker is eenvoudig en krachtig, maar biedt lang niet alle mogelijkheden die je bij een SQL databank kan hebben.

 

Sommige SQL databanken laten bijvoorbeeld ook toe om temporary tables te hebben op gebruikers niveau. Ook dat is vreemd aan FileMaker.

 

Ik heb dat echter nog nooit als een echte belemmering ervaren.

 

Koen

[geenbericht]

voor zover ik weet is een van de krachten van FM de geweldige "front end" met scale aan interface en vormgeving mogelijkheden.