How to duplicate found records?

[gsunglao]

Hello all,

I got bunch of records (as a result of find). How can I duplicate them in one go?

I tried loop but when I used exit when the last record is hit, it exits right away because when the first record is duplicated it goes right down to the bottom of the list (making it the last record).

Need some help.

Thanks!

[Genx]

How many is a bunch?

You have two options... one: you can run an import of the foundset into the same file.

Two...

Set Variable[$foundCount;  Get(FoundCount) ]

If[ $foundCount > 0 ]

Loop

Set Variable[$recordNum ; Get(RecordNumber) ]

Duplicate Record

Go To Record[ $recordNum + 1 ]

Exit Loop If[ Get(RecordNumber) > $foundCount]

End Loop

End If

[gsunglao]

GenX, Thanks... I guess I'll try the first choice. Oh and to answer your question. My 'bunch' could probably about 7 to 10.

-)

[LaRetta]

You might mention that a table can't be imported into itself. I believe you'd need to export then import. I think AppleScript can do it though (duplicate whole sets without looping).

Another method which works is:

Go To Record/Request [ Last ]

Loop

Duplicate Record

... do whatever you wish to the new record

Omit Record

Omit Record

Exit Loop If [ not Get ( FoundCount )

End Loop

This will work whether working with a sorted set or not. If you need to either preserve your starting found set - or preserve only the newly created records then you can do that as well.

UPDATE: You don't even need to go to the last record to begin. I do it out of habit.

LaRetta

Edited August 11, 2007 by Guest

[LaRetta]

Oh yeah ... if sorted, it IS important to go to last record; otherwise, the second OMIT will fail. Include the Go To Last Record[] to be safe ... that's why I always add it. :(

[Søren Dyhr]

LaRetta is right, but to avoid doing something to the wrong table's records is it pretty important to declare which of the layouts the scripting should be dealing with.

However is it often a matter of duping a larger structure, where applescript really shines. If you portal have allowed the creation of related records could some really cool things be done.

tell application "FileMaker Pro"

	tell layout "Main"

		set aVar to current record

		go to (create record)

		set first item of aVar to cell 1 of current record

		set current record to aVar

	end tell

end tell

What here is achieved is that every fields data except the record ID used for the relational linking gets the present records data.

It's pretty important that the portal wearing record carries scroll bars to get all data even the data scrolled out of visibility.

--sd

Edited August 11, 2007 by Guest

[LaRetta]

Thank you, Soren! I have a folder call MEMORIZE which has over 3,000 entries. I know this Apple Script duplication is in there somewhere and I tried to find it. It's cool but ... not particularly useful if/when xplat. Still, it's very cool!

[LaRetta]

... it pretty important to declare which of the layouts the scripting should be dealing with.

I recall a conversation between Comment and JT (-Queue-) on this very subject. JT said he always includes a layout switch to be sure the script is fired from the proper perspective. Michael (Comment) said he always knows the context from which the script is fired ... point well taken. If we opened ScriptMaker for Users, it might be important but otherwise, a Developer KNOWS when a script is fired because buttons wouldn't appear otherwise. So Soren, wise though you are, I'm not sure I can totally agree with adding a layout specification because that is usually a waste of resources when the Developer KNOWS the specification to begin with.

As always, I'm willing to change perspectives when convinced ...

LaRetta :smile2:

[LaRetta]

Okay, yeah, and I'm bored on a Saturday afternoon and I'm ready to rumble. :giggle:

[David Jondreau]

I'll have a go...

I see both sides, but I prefer to have a bit of redundancy over saving a bit of resources so I don't add Go To Layout consistently, but I wish I did.

But I don't see a right or wrong either way, just a personal preference.

Edited August 11, 2007 by Guest

[Genx]

You might mention that a table can't be imported into itself. I believe you'd need to export then import. I think AppleScript can do it though (duplicate whole sets without looping).

My Bad, but a temp table could possibly solve that.

[LaRetta]

A temp table could work, Genx, but I'm inclined to manipulate data as little as possible. Every time you export/import, you risk problems; better to use Apple Script or loop right where you're at. And why create a temp table just for this?

I would tend to loop because it would be safe in either platform but ... how about script testing the platform; use Apple Script if Mac and loop if Windows? In this way, one could take full advantage of Apple Script's speed and efficiency but provide safe loop if they are on Windows.

I've been trying to switch to full cross-platform thinking and I keep hitting differences which should be accounted for (right on down to key strokes on occasion). And then again, maybe it's overkill. But why should Mac users have to use a slower method if Apple Script can handle it better? Obviously I'm just thinking out loud here ... :idunno:

[Genx]

Don't know? There's probably an equivalently quick way to do this via vb script though.

One thing I'll mention is that the sort thing never occurred to me for some reason... or rather it never really occured to me that the records might be sorted immediately after a find?

Lol, idot for the smiley shortcut, that's hilarous.

[bruceR]

No loop required.

Perform applescript:

duplicate every record

-- works on found set

[Søren Dyhr]

a Developer KNOWS when a script is fired because buttons wouldn't appear otherwise. So Soren, wise though you are, I'm not sure I can totally agree with adding a layout specification because that is usually a waste of resources when the Developer KNOWS the specification to begin with

But LaRetta you can via applescript do something to a not even visible layout belonging to what ever open filemaker file you wish to, when being on a different layout/TO.

If you take a look at the image of the object hierachy above will you see that if you address the table as such is it ignoring a found set, but even different layouts of the same table might show different found sets. How would you point at the correct found set without using "layout" ..."document" is too high up in the hierachy?

The found set needs a layout to roam in, it's an attribute to a certain state of a layout, which applescipt can address....

Check out this:

http://www.sumware.net/robfm/savingfoundsets.php

or this:

http://www.fmforums.com/forum/showtopic.php?tid/189338/post/263372/#263372

What you statement seems to suggest is that the native scripting ahead of the embedded apple scripting should make it clear for the applescripting where focus is ...but the point is that native filemaker scripts allways prompt you for which layout the following scripting is supposed to be done in.

Where applescript could follow that route, but do not nessersarily are bound to - you can declare which of the found sets in various TO/Layout combos each dealing should focus.

Applescript have a distinction between the object type cell and field as well as table and layout , if say you make a:

[color:red]set field 1 of table 1 to {1;2;3}

...will you overwrite record 1 thru 3's value in the first field

[color:red]set field 1 of layout "someName" to {1;2;3}

...will overwrite in the found set only based on the sort order, provided 3 records exists in the found set - eventhough the user might be watching at a differnt layout.

If your cursor is in the last record of a found set in listmode is:

[color:red]set cell 1 to "abcd"

...not writing in the current record, but the first in the found set, while:

[color:red]set cell 1 of table 1 to "abcd"

...ignores the found set and writes to the tables first record ever.

[color:red]set cell 1 of current record to "abcd"

...makes filemaker deal with the record the use is in.

[color:red]create new record

...doesn't mean that applescripts foucs suddently is there. You need to:

[color:red]show(create new record)

....which singles it out as a found set of one record:

[color:red]go to(create new record)

...is what it should be to replicate filemakers own New Record!

I hope that these examples illustrates focus issues often dealt with when debugging embedded applescripts, and perhaps my idiosyncratic urge to define focus as stringent as posible

--sd

Edited August 22, 2007 by Guest

[gsunglao]

whoa... english people, english! -)

Anyways, I did not expect to really go beyond export and import (that actually worked for me). But I appreciate all the inputs. Apple script is a littlebit to far for me.

[Søren Dyhr]

whoa... english people, english! -)

Sorry, Dan'glish is the closest you get, from my scriplings!

May I suggest, next time - in my neck of the woods, to drop by:

http://www.studieskolen.dk/corporateandprivate/danishforforeigners.aspx

But one thing is learn all the words, the grammar ...but the discourse - dear me! Nicely illustrated by these lyrics:

http://music.yahoo.com/vid-18367227--Help-Somebody

--sd