Records dupliceren met gerelateerde records in portalen

[Luc De Groote]

Ik heb me rot gezocht om dit probleem op te lossen en uiteindelijk een manier gevonden. Ik versta zelf maar half hoe het werkt maar het werkt ...

Op Clarify had ik iets gevonden maar er staat altijd wel net iets te weinig informatie voor een beginneling om er wijs uit te raken. Ook op vele andere plaatsen op het internet zijn dingen te vinden die ... ja ook weer net ietrs te weinig infor geven om verder te kunnen

 

Ik veronderstel dat nog anderen met dit probleem worstelen, vandaar het bijgaande voorbeeld.

 

Indien er slimmere mensen dan ik, betere of meer elegante oplossingen hebben ... laat maar komen!

Dupliceer record samen met gerelateerde records.fp7

[andries]

ziet er op zich goed uit.

 

Voor grote data sets kan je beter ipv te loopen over je gerelateerde records, ze gewoon even exporteren en terug importeren, en dan met een replace field contents de nieuwe ID toekennen.

 

Verder een tip: als je over je records gaat lopen, is het echt aan te raden je script met een "Freeze Window" te beginnen, dat zal de snelheid aanzienlijk verhogen.

[JeanWM]

Here we go again.

En ik ben niet gewoon (meer) om nederlands te praten/schrijven (for the record).

 

Je loopt handmatig door je bestaande relaties. Wat als er later een relatie bijkomt?

 

Laat FM de relatie bepalen en hoe diep ze gaan (tier).

Die informatie drop je, dmv een script, in een soort pivot table.

Die pivot table link je met iedere TO van de toepassing.

Als je ooit een TO bijmaakt mag je natuurlijk niet vergeten om ook je pivot table mee te linken.

 

Een script zal omgekeerd door die lijst loopen en de nodige records aanmaken.

 

Om de tiers te bepalen heb je het data model EN het database model van de toepassing nodig.

 

Bij het dupliceren gaat het om data en niet om de keys. Je maakt voor ieder nieuw record een nieuwe key aan.

Dat is het deel dat NIET meekomt tijdens het dupliceren.

Je keys zijn er om een record uniek te maken, ook een gedupliceerd record.

 

Wat wij doen met deze techniek is niet zozeer de records dupliceren, maar wel de hierarchy van de relaties.

Daardoor worden de records eigenlijk automatisch aangemaakt.

[Luc De Groote]

Bedankt voor de reactie.

In mijn geval gaat het steeds maar om één record per keer waar wél heel wat gegevens in staan (meer dan 1000 velden) vandaar de noodzaak om op een bepaald moment te gaan dupliceren zodat de gegevens die gelijk blijven niet opnieuw moeten worden ingegeven.

 

Voor alle duidelijkheid; in mijn voorbeeld staan 4 scripts. De eerste drie waren probeersels die niet werken (en eigenlijk uit het voorbeeld verwijderd hadden moeten worden). Enkel script 4 werkt.

[Luc De Groote]

Jean, het spijt me maar ik versta niets van je aanbevelingen.

"Laat FM de relatie bepalen en hoe diep ze gaan (tier)." Hoe doe je dat?

"Die informatie drop je, dmv een script, in een soort pivot table" Hoe doe je dat?

"Die pivot table link je met iedere TO van de toepassing." Wat is een TO? en hoe link je die?

enz...

 

Ik ben geen doorwinterd Filemaker programmeur, net zoals de meesten op dit forum denk ik en er zijn zoveel dingen die je eerst moet weten vooraleer je zelfs maar je uitleg kan snappen. Het zijn juist de dingen zoals hierboven die voor jou blijkbaar zelfsprekend zijn, die het plebs zoals ik, naar deze site laten komen om wat hulp te krijgen...

 

Je zegt dat ik "handmatig" door mijn relaties ga. Ik doe dat toch met een script? Als je bedoelt dat ik mijn script moet aanpassen wanneer er een nieuwe gerelateerde tabel wordt aangemaakt en de toepassing dus wordt uitgebreid, dan is dat natuurlijk correct.

[JeanWM]

 

Je zegt dat ik "handmatig" door mijn relaties ga. Ik doe dat toch met een script? Als je bedoelt dat ik mijn script moet aanpassen wanneer er een nieuwe gerelateerde tabel wordt aangemaakt en de toepassing dus wordt uitgebreid, dan is dat natuurlijk correct.

 

Dat is wat we met handmatig bedoelen, je moet telkens je script aanpassen wanneer er ook maar iets verandert.

 

Een TO is een Table Occurrence, native to FileMaker.

 

"Laat FM de relatie bepalen en hoe diep ze gaan (tier)."

Door gebruik te maken van FM Functies, hier gebruik je Get(LayoutTableName), dat geeft je een lijst van tables.

RelationInfo() geeft de informatie van de relaties.

Die info breng je samen in een variable, waar je de enkelvoudige data kunt uithalen met GetValue()

 

"Die informatie drop je, dmv een script, in een soort pivot table"

Je maakt voor iedere TO die je hebt een corresponderende pivotTO aan.

Daar bewaar je de keyID van de records. FM weet nu welke records meespelen. Dat kan 1 record zijn of n, maakt niet uit, de GetValue() zal wel stoppen wanneer er geen records meer zijn.

 

Vermits iedere pivotTO gelinked is met iedere basetable, heb je automatisch een link naar ieder record dat je nodig hebt.

PrimaryKey in de baseTable = foreignKey in de pivotTable = foreignKey in de childTable (en mogelijke onderliggende tables)

 

Alle key data breng je in een global field.

Daar heb je nu alle informatie die je nodig hebt, de keys van de records en alle tables die deel uitmaken van de relaties gekoppeld aan je base table,

Dat is de table vanwaaruit je vertrekt.

 

Een tweede script neemt die informatie regel per regel (table/record) en maakt een record aan voor de aangegeven table (komende uit de lijst aangemaakt door Get(LayoutTableName).

Het resultaat is dat er in iedere nodige table een record wordt aangemaakt met de juiste foreign key terugkerend naar de initiele basetable, waar een nieuw record werd aangemaakt met, uiteraard, een nieuw primaryKey.

 

Je dupliceert dus eigenlijk niet de records, maar wel de relatiestructuur.

Dat dwingt dan ook FileMaker tot het aanmaken van records.

Vermits dat verloopt volgens de bestaande relatiestructuur, heb je al de records ook aangemaakt door die structuur te volgen.

 

Het komt er dus op neer om een goed doorzicht te hebben in relaties en een sluitende manier te gebruiken voor het aanmaken van key fields, terwijl het gebruik/kennis van de Let() en variables ook een belangrijke rol spelen in een ietswat hoger niveau van scripting.

[Luc De Groote]

Dat is tenminste een uitleg zie. Bedankt. Ga dat een keer bekijken en kom ongetwijfeld terug met nog meer vragen

[Luc De Groote]

OK, ik heb mijn voorbeeld (eindelijk) ook aan de praat gekregen in mijn eigenlijke toepassing (klein stom probleempje natuurlijk) en kan nu proberen om de betere oplossing van Jean te gebruiken. (Kwestie van eerst vooruit te kunnen en dan te verbeteren...)

Hoewel ik best bereid ben om een paar nachten via trial en error vanalles uit te zoeken en te proberen gaat dit mijn FM petje momenteel toch wel een heel stuk teboven blijkbaar Jean.

Heb je soms ergens een voorbeeld(je) liggen zodat ik wat meer richting krijg?

 

In mijn voorbeeld moet ik voor ieder portaal een (sub)script schrijven. Op zich niet zo'n daverend probleem gezien mijn toepassing wellicht niet zo heel veel zal veranderen in de toekomst maar ik heb nogal wat portalen en dus nogal wat (sub)scripts. Het lijkt er op alsof jouw oplossing met één script meteen alle portalen dupliceert, hoeveel of hoe weinig er ook zijn. Dat is uiteraard heel wat eleganter maar zoals gezegd, een voorbeeldje zou me wellicht veel verder op weg zetten dan nog een paar bladzijden vragen en antwoorden.

Dank bij voorbaat.

[JeanWM]

Zoals gebruikelijk zal ik een vrijwilliger aanduiden die iets in mekaar zal moeten steken voor jou.

 

Het kan waarschijnlijk even duren want het is hoger dan advanced scripting, en daar lopen er voorlopig nog niet ( niet meer) zoveel rond hier.

[Luc De Groote]

Allé, 'k moet dus blijkbaar niet gefrustreerd zijn omdat ik er niet aan uit kan.

 

In ieder geval bij voorbaat dank aan de aangeduide vrijwilliger !

[JeanWM]

Het zal effe wachten zijn.

 

We zitten volop in de verlengde cinco de Mayo.

[JeanWM]

Voorbeeld file als assigment in lab.

 

Credit: Anna Castilo. Zette het in mekaar in 2 uur labtijd.

 

Note: LDG staat voor Luc De Groote, kwestie van sporen bij te houden.

JWDuplicateLDG.zip

[Luc De Groote]

Wel, wel, zelfs in Mexico en zelfs in een nasleep van de Cinquo de Mayo is "een tijdje duren" toch wel heel vlug vind ik.

Heel hartelijk bedankt. "Het zal wel een tijdje duren" vooraleer ik snap hoe dit in mekaar gezet is (hierbij denk ik eerder in termen van maanden of misschien zelfs jaren en niet dagen voor alle duidelijkheid ....) maar ga zeker en vast een keer kijken of je opdracht aan je vrijwilligster correct is uitgevoerd en "het script zo is uitgevoerd dat het om het even waar in de toepassing" kan gebruikt worden

In je opdracht vergat je nog te vermelden dat het script ook fool proof moest zijn

Ik laat "binnenkort" nog iets weten!

 

In ieder geval nogmaals bedankt!

 

Luc

[JeanWM]

De gebruikte techniek heeft als basis de shunting, een vaak gebruikte werkwijze in databases.

 

Waar we vroeger een shunting, tunneling of bipolaire matrix gebruikten, kunnen we het nu doen met variables en de Let() functie.

 

Het enige dat we nodig hebben is een soort van pivot table.

Dat vangen we op in de relationships graph met de pivot tables, wat steunt op de inverted matrix techniek.

 

Al het andere wordt samengebracht in een script dat eerst een mapping script aanroept en het resultaat daarvan verder gebruikt om via een vorm van shunting de records aan te maken via de pivot table, maar in iedere TO die een link heeft met een pivot table.

Daarom dat het belangrijk is om in een toepassing te bepalen of een aangemaakte TO een link moet hebben met een pivot table/TO.

 

Het is niet echt FileMaker, het is een database techniek aangepast voor FileMaker, met native FileMaker functies.

 

We hebben het uitvoerig getest op gebruik even waar in een toepassing. Je moet enkel binnen de context van de base table blijven, en dat is niet altijd duidelijk.

 

Zoals ik zei, we dupliceren niet de records, we dupliceren de relatie structuur.

[andries]

He Jean

 

ik ben echt onder de indruk van de snelheid waarmee dit werkt.

 

mooi voorbeeld!

[JeanWM]

Credit gaat ook en misschien wel vooral naar Ray Cologon ( see About).

 

We waren (2006) op zoek naar een methode in FM om hetzelfde resultaat te bereiken dat we hadden in Sentences.

Een transactional database management systeem, gebaseerd op het associative model.

 

Tot FM5 konden we enkel de bipolaire methode gebruiken omdat de relaties enkel tussen files was in FM.

 

Met FM 7 en de multi table, variables en custom function en de hulp van Ray voor de technische kant konden we een resultaat bereiken zoals in het voorbeeld.

 

In mijn lectures leg ik het principe uit en de studenten moeten het omzetten in praktijk.

 

Tot nu toe slagen ze er vrij aardig in.

[andries]

ik ben nog hard bezig met het onderzoeken hoe het nu allemaal exact werkt