Hi,

Is there a way to use the GTRR script step by defining the destination table and the destination layout with a variable?

Edited January 28, 201015 yr by Guest

Nope.

P.S. I would also love something like this.

GTRR action

Edited January 28, 201015 yr by Guest

But I want one :tears:

Is there a way to use the GTRR script step by defining the destination table and the destination layout with a variable?

Yes there is, by redefining the relational structure to merge all related tables into one single... Read about "Tiered Tables" in David Kachels whitepaper:

http://www.foundationdbs.com/Downloads/WhitePaperForFMPNovices.pdf

The developer would then know there only is one table to make a series of request, since the foreign key fields are just as searchable as ordinary fields.

From there run the duplication scripting ... we talked about in the other thread.

However you can twist the approach to allow GTRR'ing by making the entire system rely on two criteria keys, in order to have one single common key... study the template...

It's by the way perhaps beneficial for you watch this movie...:

http://www.filemakermagazine.com/videos/data-tagging-classification-vs-organization.html

...since the urge to script comprensively is often structurally or rather lack of based!!!

--sd

el_pablo.zip

Edited January 29, 201015 yr by Guest
Added a file

I attached a modified version in which I added a distinct table.

How would you duplicate this table which add another level of depth? and if we have more levels?

Do we have to add nested loop?

Other than the main subject.

I like this example, which make me understand a new concept of flagging method. I'm already using something similar, but on the parent side for photos.

I also like the original "xor 1" to tell if it's empty. :

el_pablo.zip

How would you duplicate this table which add another level of depth? and if we have more levels?

Do we have to add nested loop?

Every time you have a grandparenting issue, must the question be if a recursive structure would suit it better, although I need to ...as well as do some thinking for a while!!

--sd

I agree with you that this is a brain teaser.

The limits of GTRR are seen here.

In my case, I'm finishing a script that duplicate a report with 30+ different tables down to 4 level of depth. The script I've done is quite heavy. The only part I could generalize was for "leaf" tables which I based on your idea.

Excuse me for saying this, but mu hunch says that there is something utterly wrongly normalized - since according to this is every business model falling within 7 sorts of ERD without exception:

http://www.amazon.com/Modeling-Theory-Practice-Graeme-Simsion/dp/0977140016

I havn't read it yet, but what if they're correct? One of the biggest problem is that you keep your line of questioning absolutely abstract ... but you of all people might have a chance to understand the math behind relational theory, but approaches the thing by trial and error, and hunches alone, deliberate pulling techniques from other fields, without seeing if they really should fit - why?

Start by Replying Bruce in the other thread, with a propper context and purpose description ... whithout which most of would give stabs in the dark only. But as such must your solution be inadequately normalized???

--sd

Thanks for asking for the normalization. I will try to simplify the question in the other thread.