Portaal gebaseerd op ander portaal

[SPORTACO]

hallo,

ben nog maar juist aan het overschakelen van msaccess naar filemakerpro. Is een hele boterham!!

kan iemand me uitleggen hoe ik gegevens in een portaal afhankelijk kan maken van gegevens uit een ander portaal?

hoofdtabel is "gezin", portaal bevat de leden van het gezin, en nu zou ik van elk van de leden van dat gezin (in een ander portaal veronderstel ik) een aantal inschrijvingen willen koppelen.

kan iemand me op weg helpen? Heb mijn testbestandje bijgevoegd.

 

guy

test2.fp7

[fmwebshop]

Misschien kom je hiermee verder.

 

Vriendelijke groet,

Harry

test2.fp7

[SPORTACO]

Bedankt

helpt inderdaad

weer beetje slimmer geworden

[Ari]

Hoe smaakt de boterham?

[SPORTACO]

de boterham smaakt goed maar het is een heel andere manier van denken.

ik denk wel dat het praktischer is dan access eens ik het gewoon ben

voorlopig bloed, zweet en tranen

maar met jullie hulp gaat het wel lukken

[SPORTACO]

Harry,

klein vraagje

je hebt ook de tabellen en relaties veranderd. waarom heb je deelnemersid in tblgezin gezet? en dan gekoppeld aan tblinschrijving.

kan een gezinsid samen met een deelnemersid in 1 tabel?

één gezinsid kan toch veel deelnemersid s hebben

versta het niet

[fmwebshop]

Het werkt nu toch?

Zo is het dus goed...

 

Wat niet mogelijk is is om een volgend portaal te tonen op basis van een gegeven in een eerder portaal.

Dit omdat het laatste te tonen portaal niet kan "weten" vanuit welke portaalregel je wilt relateren.

Je moet relateren vanuit de tabel van de layout waarin je je portaal wilt tonen.

 

Even over nadenken, hoop dat het dan duidelijk wordt.

 

Gr

Harry

[SPORTACO]

jawel het werkt zelfs prima

nu versta ik ook waarom het zo moet, bedankt

[F.J.]

Hoi,

 

Zoals met vele dingen binnen Filemaker zijn er verschillende wegen die naar 'Rome' leiden.

 

Kijk maar eens naar het bestand wat ik heb bijgevoegd.

 

Succes.

 

Met vriendelijke groeten,

 

Fred

Test3.fp7

[Ari]

Ik heb het bestand van Fred niet bekeken dus misschien was dit ook zijn oplossing maar met het setten van een ID in een globale variabele dmv een scriptstap kun je altijd elk gerelateerd record laten zien door een relatie te maken met het globale veld.

 

Dus als je op een bepaalde portaalrij klikt zorg dat de ID van deze portaalrij in het globale veld wordt gezet

[fmwebshop]

Ari,

 

Je hebt waarschijnlijk over het hoofd gezien dat dat precies is wat er in mijn voorbeeldje gebeurt?

 

Een globaalveld lijkt mij hier niet op zijn plaats omdat je daarmee dan in alle records tegelijk dezelfde relatie legt.

Volgens mij kan het niet compacter dan dat ik heb gedaan, er rekening mee houdend dat SPORTACO een beginner is en er iets van op moet kunnen steken.

 

Vr groet

Harry

[andries]

bedenk dat dit wel niet in een multi-user omgeving te gebruiken is.

 

Als 2 personen naar dezelfde record aan het kijken zijn, en iemand selecteert een gezinslid, dan zal voor beide personen de portaal veranderen. Om dit te omzeilen zal je toch naar een globaal veld moeten gaan. Je zou dit globaal veld kunnen updaten met een trigger "OnRecordLoad", op die manier omzeil je het probleem dat Harry aankaartte.

[Ari]

Ik heb inderdaad je voorbeeldbestandje niet bekeken Harry. Juist om de reden die Andries noemt moet je in dit soort situaties met globalen werken. Deze zijn pers sessie dedicated per gebruiker dus die hebben geen last van elkaars ingevoerde waarden.

[ovvk]

@andries

 

Jij gaat er vanuit dat een globaal veld altijd één waarde geeft in de totale tabel voor alle gebruikers.

Dat lijkt zo als je het bestand single user gebruikt.

Echter wanneer je met meerdere gebruikers van één bestand/tabel gebruikt maakt krijgt iedere gebruiker zijn eigen globale waarden in deze velden.

Heel erg handig in multi user omgevingen. (Wanneer een bestand met tabellen multi user gebruikt wordt, dan worden alle bestaande globale velden leeg gemaakt!)

Harry heeft hier m.i. de beste manier geschetst om een meertraps portaal raket af te vuren.

Selecteer een row in de eerste ---> set in script het globale veld met de vereiste waarde overeenkomend de onderliggende realatie uit de tabel

en de tweede portal zal keurig alle records weergeven die binnen de relatie gedefinieerd zijn.

 

cor

[Ari]

Andries weet dit ongetwijfeld wel en ik begrijp je redenering niet. Een bijkomend gevaar als je dit niet met een globale oplost is dat er een ander persoon in het zelfde record aan het wijzigen is zodat het veld niet gewijzigd kan worden. Daarnaast lijkt het me nogal spannend als ik opeens portalen zie wijzigen omdat m'n buurman ergens op klikt.

[fmwebshop]

Interessante discussie?

Ik denk dat iedereen onder bepaalde omstandigheden iedereen gelijk heeft.

 

We moeten nog even kijken naar de vraag, waarin sportaco een oplossing zoekt voor zijn probleem.

Kennelijk heeft hij nog geen duidelijk beeld van Fm relaties en hierbij wat hulp nodig.

 

Ik ben er in een wilde aanname van uitgegaan dat sportaco iets in de sport deed en dat hij als FM beginner een toepassinkje aan het bouwen is om inschrijvingen voor diverse sportlessen te beheersen voor een school of sportvereniging.

Naar alle waarschijnlijkheid geen een zware multiuser toepassing en de kans dat meerde clients in hetzelfde record moeten werken schat ik zomaar dichtbij 0.

Hier nu is het een comfort voor de gebruiker om het veld in te stellen IN het specifieke record zodat de opgeroepen portaalinhoud behouden blijft, ook als hij even naar een ander record gaat.

Ik zou aan deze oplossing willen toevoegen een veld boven het portaal met de opgehaalde naam van de "portaaleigenaar" om vergissingen te vermijden, dit zou echter mogelijk tot verwarring kunnen leiden bij het doorgronden van de oplossing bij sportaco en heb ik dus vermeden.

 

Vriendelijke groet,

Harry Bakker

[SPORTACO]

heren

 

inderdaad een levendige discussie die soms mijn petje te boven gaat. FM is een andere manier van werken dan access. Maar we leren bij.

 

harry, ik organiseer sportkampen. deelnemers die op een bepaalde locatie, één of twee sporten kiezen in een bepaalde week van de vakanties. Dat is de basis van alles. In bijlage een kleine schema met veel rommel op.

 

guy

[ovvk]

@guy

 

Filemaker is soms wat eigenzinnig maar als eenmaal het kwartje bij je gevallen is dan wil je eigenlijk nooit anders meer.

Ik heb nu professioneel een aantal keren FM ingezet en ik moet zeggen dat de klant leercurve heel erg laag is, en de

klanttevredenheid is heel erg hoog.

En zelfs bij Digibeten werkt het prima.

Verdiep je in de opbouw van de relaties in FM! en alles zal helder worden.

 

En met veel proberen, veel zuchten en af en toe je project het raam uit willen gooien en toch vol blijven houden maak je

aan het einde van de dag een product dat hartstikke lekker werkt en je je afvraagt waarom ben ik niet eerder overgestapt op Filemaker.

 

cor

[pjotter]

Beste SPORTACO, als zeer trouw FM en Acces gebruiker ben ik erg benieuwd hoe je dit probleem zou oplossen in Access?

Je geeft aan dat je aan het overschakelen ben van Access naar FM dus ik neem dus aan dat je met Access beter overweg kunt (had zelf die ervaring paar jaar geleden ook).

Om die reden weet ik ook dat je beter in het begin eerst de Access oplossing kunt maken (die ken je immers) en dan een schermafdruk maken van de gemaakte relaties. Zeker als je dit probleem in Acces kunt maken (zal gezien de vraag en het bijbehorende antwoord wel een rapport worden?) zul je er versteld van staan hoe eenvoudig FM dan is in vergelijking met Access.

[SPORTACO]

had daar juist een pdf met de relaties in access als bijlage maar geen pdf toegelaten blijkbaar

[pjotter]

Gewoon een JPG van maken die geeft geen probleem

[SPORTACO]

hey

 

hier dan toch mijn relatieschema in access. Op veel plaatsen geen relaties maar de voornaamste staan erop.

[pjotter]

Dit is inderdaad een relatie schema van access alleen kun je hier geen soep van maken

Op basis van dit schema kan ik niet inzien dat je een werkend formulier hebt wat je nu in FM wilt hebben,Ik lees nu het hele stuk door (helaas weinig tijd dus ik kijk vaak koppen ) en zie dat het al werkt met het voorbeeld van Harry dus daar kun je vanuit verder bouwen. Je kunt ook elke tabel uit access omzetten naar een excel bestand en importeer deze in je FM bestand en leg de relaties op dezelfde manier dan kom je een heel eind in een werkend produkt en de oude data die je dan kunt importeren. Ga daarna fine tunen dat is in FM perfect te doen.