Repeating fields, follow-up question

[duckster]

I was grateful for the explanation earlier of the GetRepetition function and I have used this. However, I'm also looking for a way for the user to copy the data from a particular repetition to a non-repeating field. For example,

Repeating field

A

B

C

D

If the user clicks on D, I want the data to copy over to a non-repeating field. If I make a script to copy and paste it just copies the first repetition. Is there a way I can get it to copy the repetition that has the focus? Thanks.

duckster

[Søren Dyhr]

Make an invisible button over each repetition, that calls a script holding 1 line:

Set Field(recieverField;GetRepetition(myRepeat;NN)

...where NN changes for each script.

However having said that must I urge you to stop using repeaters, and instead use portals and relations. Because you soon will start to ask where is my SetRepetition( command.

--sd

[Raybaudi]

Hi Soren

each repetition in FM6 ??

better the second yoy said !!

[duckster]

Thanks, I'll try it. I don't normally use repeating fields but the file was created by someone else and I'm trying to make a few changes to it.

duckster

[macmangler]

OK... I give up... where is the set repeated field button?

I am half kidding... I could not help jump in on this. I am picking up an old database that I did not create, and every important field is repeated fields. I am depressed about it. Being that I am updating everything, my solution was to rebuild the document within the the document and everything linked fine. Eventually, I will make this database all new, and save the old for "HISTORY" and finding old jobs... not too worried about this one.

Anyway... I agree to always build with single fields... I have a dilemna though. I am fine tuning my invoicing side of programming....QTY, DESCRIPTION, UNIT COST AND EXTENDED COST. The description is a look up against an ITEM database... works so welll with repeated fields.

If I do separate fields... I have 10 of them, I would need 10 different value lists for the ITEM look up, and 10 separate relationships?

I am torn for direction.... I agree I can not "SET FIELDS"... but the alternative is messy in this case.

Whats your oppinion?

Edited August 6, 2006 by Guest

[Genx]

...Why would you need 10 different value lists for the item to look up?

[macmangler]

Time out.... perhaps your right!

Edited August 6, 2006 by Guest

[macmangler]

OK... you are right, I do not... I mis read your response....

and I was just double checking my test files... I only use one value list for the description, but it is still 10 unique relationships... it is going to be messy.

I have....

QTY

DESCRIPTION

UNIT COST

EXTENDED PRICE

COST

TAX

TAX and UNIT COST are look ups....

Repeated fileds makes this one relationship and (6) Fields. If I opt for the, perhaps the correct way, I am looking at 10 relationships and 60 fields to start with...

I am depressed. Maybe you all do this for a living... perhaps a few hours of work.... I don't do this for a living.... but, I possibly could... I got pretty good at this though.

This is a few extra hour s programming and serious testing to make sure I didn't screw up anything....

Edited August 6, 2006 by Guest
obvious typo

[macmangler]

OK... I am whining.

Sorry.

The correct decision is to make all the 60+ fields. It won't really take hours... but it will be messy. My files are so meticulous... so I am depressed about it.

I know in the long run, I will appreciate the the extra work. My files will have more potential for growth... the "Set Field" command alone.

[comment]

No, the correct decision is to make a related LineItems table. This is from Filemaker Help > Working with related tables and files > About relationships:

For example, a typical Sales database may have these tables: an Invoices table, which keeps a record of each invoice; a Products table, which stores the products and their current prices; and a LineItems table, which stores sales data for each line of the invoice, including the item being sold, the quantity, and the price at which it is sold. Because invoices are a mix of dynamic and static data, you use both related fields and lookups to display your data. Records from the LineItems table are displayed dynamically, in a portal on the Invoices layout, but the actual sales price of each line item is entered using a lookup, so the invoice totals remain the same, even if prices change at some future date.

[macmangler]

Nice find... I will read more about it.

Thanks

[Fenton]

I would second comment's comments :-] Further, you have FileMaker 8 Advanced. You can copy/paste your current repeating fields, as structure, to a new table. Open each field's options and quickly set it back to 1 Repetition (calcs also). Then import your current data into the new table. A 2nd dialog of the Import will ask (radio buttons), "Split repeating fields into separate records?" Select that. As long as you also import the parent ID, you will have a pretty much functioning related table of your repeating data; just connect the ID relationship.

Then you can even go to your current layout, reassign the 1st row of the repeats to the related table. Surround it with a portal. Give it the same number of rows. It will look the same, it will function the same. You only need to make slight changes to the "totals" fields remaining in the parent table. For example:

Sum (repeating field extended price) becomes Sum (related extended price)

Sum() works the same for a repeating or a related field (though the latter is unstored; that is the price you pay).

You can then delete the repeating fields. I'm not saying you have to do it, I'm just saying it ain't that hard to convert.

[Genx]

comment's comments ...

AHhahahahahAHAHAAhahahaha.