Dupliceer record incl portaal records

[Pasav]

Ik ben op zoek naar een manier om een record te dupliceren inclusief eventule portaal records. Ik vroeg me af wat de ervaringen daar mee zijn hier. En wat de slimste aanpak is.

 

Alvast bedankt voor het meedenken.

[Bruno]

Kun je geen bestandje met testgegevens posten ?

[hiker]

Ik heb dit ooit wel eens gedaan maar weet niet of dit de meest optimale manier is:

- nummer van hoofdrecord in variabele1 opslaan

- hoofdrecord dupliceren

- nummer van gedupliceerde record opslaan in variabele2

- naar gerelateerde tabel

- alle records zoeken met nummer=variabele1

- via loop alle gevonden records dupliceren en nummer=variabele2 instellen

 

Zo moet het lukken.

[trikke]

http://www.filemakerpros.com/DUPPORT.zip

Is al heel oud (FP3), maar doet de truuk nog steeds. Kan wat modernisering gebruiken voor FM11.

 

Ga naar related (nieuw venster)
Selecteer origineel venster
Dupliceer record
Variable zetten $parent_id = id
Selecteer nieuw venster
Loop
Dupliceer
set parent_id ->$parent_id
weglaten
Ga naar eerste
weglaten
exit loop if Get(FoundCount) = 0
End loop
Sluit venster (nieuw venster)

[rutgerm]

In bijlage een voorbeeld zoals ik het indertijd geprobeerd heb om offertes met calculatielijnen te kopiëren, werkt maar waarschijnlijk kan het beter.

Comments zijn altijd welkom.

Duplicate portal.fp7

[Pasav]

Bedankt voor de input, ik ga eens kijken hoe dit uitpakt voor mij.

[andries]

Comments zijn altijd welkom.

 

 

persoonlijk opteer ik voor de import export methode, zeker als de data set van gerelateerde records groot is.

 

Dan doe ik meestal

 

GTRR

Export records

Import records

Replace foreign key

 

Dit gaat echt super snel, geen geknipper op windowsmachines etc.

[JeanWM]

...en wat gaat er gebeuren indien de GTRR geen RR heeft?

[Pasav]

Bij mij gaat die dan alle record van de tabel importeren. Dat is nou weer even jammer, en kijken hoe te tackelen.

[andries]

je checkt natuurlijk eerst of er RR zijn

 

het is maar een principe dat ik even wou duidelijk maken, geen kant en klaar script.

[Pasav]

Ja oke, denk het makkelijkst met een berekening die checkt of er RR zijn.

[JeanWM]

je checkt natuurlijk eerst of er RR zijn

 

het is maar een principe dat ik even wou duidelijk maken, geen kant en klaar script.

 

Hoe zwaar het woord 'natuurlijk' kan doorwegen.

 

Voor beginners is het niet eenvoudig om het doorzicht te hebben wat er kan gebeuren.

 

Hetzelfde is voor overspringen naar een line-item layout, daar wat dingen te doen en dan terug te gaan naar 'original layout'.

Beter is het dingetje altijd bij naam te noemen, gebruik de layout naam of, zelfs beter, de layoutID.

Een script zal nooit breken indien je de ID gebruikt.

 

En zorg ervoor dat je bij het 'terug gaan' opnieuw op het juiste record terecht komt.

Je moet dus bij het begin van de routine het record (parent key) meenemen.

[Ari]

In van tevoren checken of er childrecords zijn schuilt het gevaar dat na het verwijderen van een childrecord enkel de juiste waarde wordt teruggegeven als het parentrecord na het verwijderen wordt vastgelegd. Als je deze scriptstap vergeet bestaat het gevaar dat het script wordt uitgevoerd zonder dat er daadwerkelijk childrecords zijn.

 

Geef elke tabel een uniek ID in een berekeningsveld. Als je de opdracht geeft naar de gerelateerde records te gaan en daarna checkt of je in de childtabel bent terecht gekomen kan het nooit misgaan