Corneel

@chubbie Juist, dat was wat ik over het hoofd zag: niet werken vanuit de join-table, maar vanuit de studenten table. Bedankt voor de tip! Corneel

@ hiker Zo dacht ik ook en heb ik ook gedaan, maar dan krijg ik alle studenten van 2009-2010. En ik wil juist dat filemaker die studenten laat zien die niet meer ingeschreven zijn in 2010-2011. In de join-table staan bijv. studenten A,B en C die alledrie ingeschreven waren voor 2009-2010. Alleen student C heeft zich opnieuw ingeschreven voor 2010-2011. Als ik nu deze join-table laat doorzoeken op toon jaar 2009-2010 en een 2e request laat 2010-2011 weg, dan toont filemaker studenten A, B en C. En ik wil dat FM dan alleen A en B toont. Hoe krijgen we dat voor elkaar?

Beste mensen, In mijn database van studenten die cursussen volgen gedurende meerdere schooljaren wil ik zoeken op alle studenten die bijvoorbeeld in schooljaar 2009-2010 een cursus gedaan hebben, maar zich niet opnieuw ingeschreven hebben voor het volgende schooljaar 2010-2011. In mijn database heb ik een table met studenten, een table met cursussen en 'ertussen' een join-table inschrijvingen, waarin het veld schooljaar staat. Deze laatste tabel is dus gevuld met inschrijvingen van studenten op cursussen in een bepaald schooljaar. Ik zou nu graag willen weten welke studenten zich niet meer ingeschreven hebben voor het nieuwe schooljaar. Ik dacht simpel de opdracht te kunnen geven: zoek alle records met schooljaar 2009-2010 maar laat schooljaar 2010-2011 weg. Ik kom er dus niet uit: in feite zou ik binnen 1 request in hetzelfde veld verschillende criteria moeten kunnen geven: zoek 2009-2010 en laatweg 2010-2011. Dat laat Filemaker natuurlijk niet toe. Ik heb al gestoeid met constrain en extend, maar zonder resultaat. Naar mijn idee moet er zo'n opdracht te formuleren zijn, maar ik zit op dood spoor. Wie kan zijn licht laten schijnen op deze ogenschijnlijk makkelijke zoekopdracht? Corneel

Dit probleem lijkt mij getackeld te kunnen worden met een cross tab report. Bestudeer dit eens en kijk of je er wat aan hebt: http://dwaynewright.squarespace.com/display/Search?searchQuery=cross+tab&moduleId=6851414

Is dit wat voor je? http://www.briandunning.com/cf/495

@andries Op deze wijze geeft de formule inderdaad aan of de gebruiker het item "other..." heeft ingevuld. Maar ik wil nu juist in mijn rapport vermelden wat er is ingevuld bij "other..." Hoe doe je dat dan?

Op een evaluatieformulier voor kinderen heb ik bij een vraag de mogelijkheid gemaakt om meerdere antwoorden te geven. Bijvoorbeeld kan er geantwoord worden op de vraag: 'wat vond je van de les?' : leuk, saai, te lang, te kort, "other....". In het evaluatierapport laat ik voor dit veld ("wat vond je van de les") de diverse antwoorden tellen: hoe vaak is geantwoord 'leuk', 'saai', etc. De antwoorden die zijn gegeven bij 'other...' (dat is immers de mogelijkheid die je hebt als je het veld instelt met aankruisvakjes) krijg ik met een berekening niet voor elkaar. Ik heb het geprobeerd met de formule "Substitute ( FilterValues ( List ( Evaluatie::Wat vond je van de les ) ; "other..." ) ; ¶ ; ", " )", maar die werkt dus niet. Heeft iemand een idee?

Ik ben er uit! De crux zit 'm in het feit dat ik de bewuste portal gebruik als filtered portal, m.a.w. gestuurd vanuit de parent TO middels een global field. In het script heb ik nu ook het veld, gerelateerd aan dit global field, gevuld met dit global field. En voila! Weer wat geleerd! Dank voor het meedenken! Corneel

@rmw 'Allow creation of records' staat uit. Via het script maak ik een nieuw record aan in de child table.

Ik heb advies van fmwebshop opgevolgd: nieuwe portal gemaakt, nieuw script: geen succes. Daarna heb ik portal en script verwezen naar een andere TO: bingo! Dus de TO waarna ik verwijs in het onwillige script is de boosdoener, lijkt mij. Nu dus buig ik mij het hoofd over het verschil in die 2 TO's. De 'telefoon-TO' (zie voorbeeld in mijn vorige bericht) is zeer simpel met slechts 3 velden. De TO waarmee het mis gaat omvat veel meer velden en heeft van dezelfde table nog een TO. Ik vraag me af of dat invloed heeft op de scriptstap "Go to portal row'.

Dit is het script dat ik gebruik. Zoals gezegd werkt dit prima. Het brengt mij bij de portal die als objectnaam "telefoon" heeft en selecteert de laatste blanco portal row. Eenzelfde script bij 2 andere TO's werkt dus niet.

Ari, Het childrecord maken is idd geen probleem. Dat doe ik via het script. En ook heb ik via Go to Object de juiste portal gekozen. Het rare is dus dat het wel lukt bij 2 andere TO's. Exact hetzelfde script en scriptvolgorde (uiteraard met op de relatie aangepaste parameters) heb ik in beide situaties gebruikt. De een werkt prima, de ander komt dus niet op de juiste portal row uit.

Er is geen sortering ingesteld, noch op de portal noch op de relatie.

Dat had ik al gecontroleerd. Het script verwijst inderdaad naar de TO die ook door de portal gebruikt wordt. Kan het iets te maken hebben met het feit dat van deze TO nog een TO in gebruik is? Zoals ik in mijn eerste bericht meldde werkt het 1e script wel. Maar daarin wordt verwezen naar een uniek, eenmalig voorkomende TO. Wringt hier de schoen? Corneel

De scriptstap 'Go to portal row - last' lijkt duidelijk. Maar ik heb in mijn toepassing 2 portals waarin deze sriptstap anders reageert. De relatie die ik heb opgezet tussen 2 tables is die zonder 'allow creating record'. Een nieuw record maken doe ik via het script. Dit script werkt zoals verwacht en maakt inderdaad een nieuw record in de child table en maakt dan een nieuwe regel in de bewuste portal. Exact eenzelfde script gebruik ik om hetzelfde te doen tussen 2 andere tables. Vreemd genoeg werkt dit script niet: in de portal wordt de laatste rij geselecteerd waar al data staat. Ik zou dus juist graag een nieuwe regel willen om nieuwe data te ontvangen. Beide portals ( die waar het script wel werkt en die waar het niet werkt) zijn eender ingesteld ( show vertical scrollbar, 3 rows). Is er iemand die door heeft waar de crux zit? Groet, Corneel