meerdere portals op 1 lay-out probleem met toevoegen records

[ovvk]

Hallo allen,

Ik zit al een tijdje te worstelen met een vervelend probleem wat best ingewikkeld is maar ik zal proberen om het uit te leggen.

Ik wil op één lay-out meerdere portals uit meerdere tabellen tonen en onderhouden.

Echter de samenhang tussen deze portals werkt als een drietraps raket.

 

1e = master

2e = detail van een gerelateerde tabel

3e = detail van de tweede gerelateerde tabel.

 

Dus als je het eerste record van portal_1 selecteerd worden de onderliggende records (uit een separate tabel) in portal_2 getoond.

Dit werkt naar behoren, in tabel_2 is een globaal veld opgenomen die via een scriptactivering in portal_1 gezet wordt.

De relatie naar Portal_2 maakt gebruik van dit globale veld.

Alles ziet eruit dat het goed werkt. Na selectie van een records worden keurig de onderliggende details getoond in portal_2

 

Echter wanneer je details wilt toevoegen in portal_2, dan wordt alleen de verwijzing van portal_1 rij_1 in portal_2 aangemaakt, ondanks dat

de filterwaarde (het globale veld uit de index) op de juiste waarde staat en dat is dus niet de bedoeling omdat dan ieder toegevoegd portal_2 record altijd onder

Het eerste record van Portal_1 komt te hangen.

 

Ben je er nog .............???

 

Goed, dacht ik, ik los het op met het vullen van een globale variabele genoemd $$tweede_verwijzing

Hierin vul ik de unieke waarde van het record uit portal_1

In de database geef ik de opdracht om het veld automatisch te vullen bij aanmaken met deze globale variabele.

Dit werkt uitstekend en de verwijzingen komen keurig op zijn plaats in de derde tabel (Portal_2)

 

Echter om een of andere stomme reden wordt er nu volledig automatisch in Portal_1 een record aangemaakt, en dat is beslist niet de bedoeling.

Ik denk, dat FM10 de tracking kwijt raakt mbt. welk portal op de lay-out er een record bij moet krijgen.

 

Ik heb test1.fp7 toegevoegd om dit probleem inzichtelijk te maken

 

Heeft iemand een suggestie hoe dit op te lossen?

Als deze methodiek niet werkt, zal ik het anders moeten oplossen en dat zou jammer zijn.

 

Mvgr,

 

Cor de Bruin

[JeanWM]

Ik heb de indruk dat je het concept van Codd niet volledig onder de knie hebt.

 

Je relaties zijn nogal verwarrend.

 

Je hebt :

'eerste_uniek' en 'eerste_ID'

 

In je tweede tabel spreek je van:

'eerste_verwijzing'

 

In je derde tabel is de 'tweede_verwijzing' een auto enter serial....

 

Is allemaal nogal verwarrend en lijkt meer op rondklikken tot er iets werkt.

 

Lees eerst de keys concepts erop na, hoe je relatiesleutels moet maken en gebruiken.

Probeer te ontdekken wat foreign en parent keys zijn en hoe ze te gebruiken.

Dan zal volledig duidelijk worden wat je moet doen om het gewenste resultaat te bekomen.

 

Op het eerste zicht zou je met compound keys kunnen werken om data in je tweede en derde portaal te tonen.

[ovvk]

Ik begrijp je verwarring Jean echter ik heb nog niet gezien dat de GUI zo reageert met meerdere portals zoals ik dat wil hebben.

Ik gebruik de "uniek /serial" velden om in ieder geval de de boel uniek te houden.

 

ik vraag mij af, hoe ik kan voorkomen dat FM in mijn "parent" portal een record aanmaakt als ik een child portal een record toevoeg?

 

en of ik nou het principe van CODD gebruik of niet, FM maakt (waarschijnlijk) door een intern event een record aan in de verkeerde tabel/portal.

en dat wil ik dus niet.

 

Ik ben filemaker gaan gebruiken, omdat ik van mening ben, dat ik een aantal zaken sneller voor elkaar kan krijgen dan met iedere willekeurige andere SQL engine.

Alleen heb ik nu niet zo veel invloed op de lay-out als ik zou willen hebben.

 

overigens vind ik het wel erg prettig dat er met mij meegedacht wordt.

 

cor

[JeanWM]

Voor zover ik kan zien doet FileMaker precies wat je vraagt.

 

Dat het niet precies is wat jij wil, is een ander verhaal, en is zeker niet de schuld van FileMaker.

 

Ik snap niet goed wat de bedoeling is van je opzet met de portalen.

 

?Wat wil je eigenlijk bereiken ¿

[ovvk]

@JeanWM

 

in eerste instantie wil ik dat de gebruiker door selectie van een Row in een portal de gerelateerde records

ziet in de naastliggende child portal (en eventueel daaruit weer verder kan selecteren).

 

Filemaker doet dat helemaal goed (voor bestaande recordsets) door het Globale veld te vullen met

de Key van aangeklikte record in de parent portal worden keurig de records geselecteerd in de child portal.

 

So far so good.

Maar probeer eens in de Child portal een record toe te voegen.

FM maakt een nieuw record aan, en vult de in de "Relaties" genoemde velden in het child record in.

Echter, dat gaat verkeerd, en neemt de verwijzing op van het eerste record uit de parent portal.

 

Dit was te omzeilen, door in het Eventscript van de parent portal een globale variabele te zetten.

Vervolgens geef je dan in de database aan dat het onderhavige veld zich via een berekening moet vullen met deze globale variabele et voila,

Het child record wordt nu gevuld met de juiste waarde. En komt dus keurig onder de Parent record te hangen. Let wel, alle portals nog steeds in één Lay-out.

 

Echter op voor mij onverklaarbare wijze wordt er direct met de Add Portal record actie in de child een nagenoeg leeg record aangemaakt in de parent portal.

Dit laatste is mijn probleempje.

 

Ik vond het wel een hele elegante oplossing om het op deze manier te bouwen echter het gedrag is ongewenst.

Mocht ik dus geen ontwerpfouten gemaakt hebben, en blijkt het een probleem van FM 10 te zijn, dan kan ik altijd nog een script event activeren, die na opslaan van

het child record, gelijk het zojuist (onterecht) aangemaakte record uit de eerste tabel sloopt.

 

Deze workaround kan ik altijd nog toepassen, maar het kost tijd, de serial seed in de parent tabel krijgt gaten en ik wil weten of ik de zaken verkeerd interpreteer

omdat ik Filemaker (soms) nog niet zo goed begrijp.

En ik gewoon dingen wil doen die niet des filemakers zijn. Dit zijn overigens wel leuke uitdagingen die ik graag wil overwinnen en ook wil delen met anderen.

Mvgr,

Cor

[rmw]

Je terminologie is wat verwarrend (eerste, tweede, derde) maar het principe is wel werkbaar.

 

Bijgevoegd een voorbeeld van hoe het wel werkt.

In tekst: door de derde tabel niet via de tweede te vullen vanaf de eerste (ik bedoel maar:verwarrend), maar direct vanaf de eerste door middel van twee globale velden lukt het wel.

 

Ik hoop dat ik je goed begrepen heb

 

rmw

test2.fp7

[ovvk]

Rmw great thinking!

 

Nooit erbij stilgestaan om de hele actie uit te voeren vanuit de eerste portal.

Nog wat schaven en schuren, en dan heb ik de proc precies zoals die moet zijn.

Het komt echt voort uit mijn ouderwetse manier van denken.

 

 

Thx

 

Cor