N:N relatie oplossen

[Hnek]

2 bestanden: Personen en organisaties. personen kunnen in meerdere organisaties zitten.

 

In de handleiding wordt dit opgelost dmv een join/gerelateerd bestand. Persid en orgid gerelateerd met het gelijknamig veld in resp. personen en organisaties en pers_in en org_in. Deze laatste twee zijn 2 calculation velden met de volgende syntax: Relatie_naam::Gerelateerd_veld.

 

Wat betekenen die 2 dubbele punten?

 

Wanneer ik in de bestanden personen en organisaties records aanmaak komen die niet in het tussenliggende "join" bestand.

 

Ik wil dus het volgende "join bestand" krijgen:

 

persid orgid

101 501

101 502

102 501

103 501

103 503

 

Zodat ik in het bestand organisaties alle personen krijg die in een bepaalde organisatie zitten, zonder dat daar extra in te vullen.

 

Henk

[AvD]

Je spreekt over 2 bestanden, maar je hebt er dus drie nodig. Dat derde, de zogenaamde Join file, heb je dat al aangemaakt? Records komen daar niet automatische in terecht, dat gebeurt via scripting. Ook het verwijderen van records moet via scripting gebeuren: als een record in een parent file verwijderd wordt (bijvoorbeeld wanneer je een bedrijf verwijdert), dan moeten de contactpersonen in de databank Contacts blijven (die gaan niet automatisch mee dood...), maar de records in de Join file moeten wél weg, nl. die records die de relatie aangeven tussen het bedrijf en de contactpersoon. Heb je het zo opgezet?

[jw]

Toch is het wel mogelijk om de record uit het ander bestand automatisch te laten verwijderen. Daartoe leg je de relatie van bestand A naar bestand B en geef je aan 'When deleting a record in this record also delete related records'.

Toch zit hier ook een nadeel aan. Als bestand erg groot is, bijvoorbeeld 50.000 records, en je verwijderd deze allen, dan duurt het aanzienlijk langer.

[AvD]

Gelijk heb je, maar ik heb die mogelijkheid expliciet niet vermeld, omdat die optie, indien onvoorzichtig gebruikt, te vergelijken is met een handgranaat verpakt in een doos met vuurwerk. Het is al vaak voorgevallen - zo bewijzen de paniekreacties op de lists - dat de relatie in omgekeerde zin een delete veroorzaakt: een record in de join file wordt gedelete omdat iemand niet meer voor die firma werkt, en tegelijk wordt die contactpersoon én die firma gedelete !

Daarom is het verkieslijk, zo zei men ons toch, te werken via scripting met voldoende warning messages...

[Stef]

Niet om te pochen, maar ik doe dit in één enkele file!

 

Dit vereist wel het "truukje" om te linken op verschillen de id's, gescheiden door "¶".

Bedrijven en personen worden gekenmerkt door een type-veldje met "B" of "P" als inhoud.

 

hth

STef

[Hnek]

OK, ik heb wat gelezen in de handleiding, relaties maken lukt nu

 

Alvast bedankt voor de reactie.

 

Bij de aanmaak van de relatie kan je ook de aanmaak van records toelaten. Dit gebeurt echter niet. Bestanden die in het hoofdbestand worden verwijderd verdwijnen wel in het gerelateerde bestand. Waar loopt het fout?

 

Kan de aanmaak zonder scripten?

 

Henk

[Stef]

jawel, maar in een portal. Lees verder, je komt dat stuk wel tegen!

 

hth

stef

[AvD]

Deze thread is blijkbaar ontdubbeld: we zitten aan twee aparte tafels te babbelen. Kan de moderator die twee tafels aaneenschuiven?

[Hnek]

Bij een portal lijkt me op het eerste gezicht de rangschikking van de velden nogal beperkt. Zit men gedwongen in de tabelvorm?

 

Zijn er jullie complicaties bekend in het geval van scripten of een portal als de databank via Instant Web Publishing wordt geshared?

 

Henk

[Hnek]

AvD, Mijn excuses, ik was dat antwoord even kwijt, blijkbaar had ik het verkeerd geplaatst.

 

Ik had me ook vergist in de terminologie.

 

Bij de maken van dat "aanmaak" scriptje zit ik met een probleem. Ik kan een ander bestand open en vervolgens een nieuwe record aanmaken of dupliceren, maar hoe krijg ik daar die nieuwe waarde in?

[AvD]

Ofwel via de scriptstappen Copy (in het hoofdbestand) en daarna Paste (na Create New Record in het gerelateerd bestand).

Je kan ook het Clipboard sparen door via een Global te werken.

 

En ja, met een portal ben je gebonden aan een tabel-vorm: rijen en kolommen, niets aan te doen. Je kan die rijen natuurlijk wel tamelijk hoog maken.

[Stef]

Je kan natuurlijk ook de portal maar één rij hoog maken en de scrollbar uitschakelen. Als je dan nog de achtergrond doorzichtig maakt en de lijn op "none" kan je velden laten verschijnen en verdwijnen. Dit is dezelfde techniek die Murtje uitlegde in het onderwerp "Een Knop actief en zichtbaar maken onder bepaalde voorwaarde".

 

hth,

Stef

[Hnek]

Na een telefoontje naar filemaker support ben ik al iets wijzer, maar het werkt nog niet helemaal zo als het zou moeten.

 

Na het aanmaken van de relatie dien je het vergelijkingsveld opnieuw aan te maken, daarna worden er wel records aangemaakt in het gerelateerde veld. Alleen spijtig dat wanneer je een veld in het hoofdbestand wijzigt het overeenkomstige veld in het gerelateerde bestand niet wijzigt , maar er een nieuwe record wordt aangemaakt. Ik ga enkele dagen op verlof. Ik ga daarna nog wat experimenteren met portals en scriptjes. Alleen spijtig dat de scriptjes waarschijnlijk niet bruikbaar zullen zijn met instant web publishing.

 

filemaker support stelde mij eigenlijk weer teleur, heeft daar iemand goede ervaringen mee? de vorige keer wisten ze niet wat een web security database was.

[Jimjams]

De weinige keren dat ik gebruik heb gemaakt van Filemaker support was bij de start van FM Pro 4.0, de eerste relationele versie. Omdat het principe van relationele database-structuren voor mij toen ook nieuw was, heb ik hun toen ook een aantal vragen gesteld. Een van mijn vragen toen, herinner ik mij, was wat de beste oplossing was; zoveel mogelijk aparte files creëren of het aantal tot een minimum beperken.

De support-rakker in kwestie drukte mij toen op het hart dat je best, en ik citeer:

...zoveel mogelijk files creëert zelfs tot aan de limiet van 50!

Met een gerust gemoed werkte ik daarom mijn toepassing volgens dat principe uit om achteraf door verschillende FM-goeroes het tegenovergestelde te horen te krijgen. Mijn vertrouwen in de support-groep had toen wel een serieuze deuk opgelopen en sindsdien maak ik er geen gebruik meer van.

 

Laten we de dingen echter wel in het juiste perspectief plaatsen.

De heren en dames van de FM support-group weten best wel waar ze mee bezig zijn maar moeten vaak met een minimum aan informatie en zonder een copie van de desbetreffende toepassingsfiles een conclusie trekken. Begin er maar aan!

Dat neemt echter niet weg dat naar mijn gevoel een forum als het deze vaak meer bruikbare oplossingen biedt dan een enkele supportman of vrouw.

Edited October 31, 2002 by Guest

[AvD]

Wanneer je ergens zwaar gewond ligt, en je hoort de sirene en je ziet de reflecties van het blauwe zwaalicht, dan denk je dat je gered bent. Dat is een nogal natuurlijke reactie. Zo zien wij ook de helpdesks: die weten alles, hebben alles al tientallen keren meegemaakt, en schudden zo meteen de oplossing uit de mouw, en zelfs aangepast aan je eigen configuratie...

ZO WERKT DAT DUS NIET ! Een helpdesk wordt geconfronteerd met de meest uiteenlopende vragen die het hele spectrum van het menselijk begripsvermogen bestrijken. Ze krijgen vragen van mensen die amper het verschil zien tussen een monitor en een draagbare tv, maar ook van zeer doorwinterde amateurs die een absoluut topniveau bereikt hebben... De vraag van de eerste is meestal onthutsend en vereist vooral de vaardigheid om ernstig en beleefd te blijven; de vraag van de tweede is beangstigend, want meestal is die vraagsteller al dieper op het onderwerp ingegaan dan de doorsnee helpdesk medewerker ooit kan doen. Bovendien hebben deze medewerkers door de geringe financiële waardering voor hun taak geen tijd om langdurig ervaring op te doen: de meesten blijven niet lang in zo'n job. Als je de hele dag met die koptelefoon op je oren zit, dan heb je amper de tijd om iets uit te proberen op de computer. Tussen twee telefoontjes in heb je niet eens de tijd om wat nota's neer te pennen of advies van een collega te vragen: er zijn nog zoveel wachtenden en... mensen wachten niet graag, weet je wel.

Als afsluiter mijn strikt persoonlijke visie: in de digitale wereld zijn we te snel te ver gegaan en dat zal onvermijdelijk gigantische problemen geven in een tamelijk nabije toekomst. Je kan dit beschouwen als een pessimistische cultuurvisie !