Is this incorrect use of Ugo solution - for self join

[Simon K]

I attach a file. (There is only one table with 3 fields and 2 TO's)

I have created a TO (called "TasksToInclude" and a layout that should only have show those tasks with the text "include" in the "TaskStatusText" field.

The TO TasksToInclude is a based on a calc field in Tasks called cTaskIDs.

The layout is showing records from Tasks but displaying related fields.

I was about to write a script that would "go to the TasksTOInclude layout and export all records (ie those records that where the TaskStatusText field = "include")

Part of the export script would have been to then set TaskStatusText field to "exported" (or maybe another date field with the date/time of export) which would be used in the cTaskIds calculation.

However - this will not work (becuase all the records are in the TO???)

Have I misused this technique - should this really be achieved by a scripted find before export?

Its not really that large a volume issue - maybe 400 tasks a day (in one export)

Would appreciate some pointers

Many thanks

Simon

Clearly not understanding Ugo ... yet!

UgoTestSelfJoin.zip

[comment]

It's not truly an implementation of the Ugo method. Nor is such implementation required here - since there is no problem with unstored fields on the "child" side of the relationship. In addition, a relationship is probably not required here at all.

It might be helpful at this point to restate some basics:

Records belong to a base table, not to any of its TO's. Any layout can show all or part of its base table's records. This depends purely on the found set, not on the layout. A found set can be created by finding/omitting, or by GTRR. The TO plays an important part in GTRR - but that's just a technique to create a found set. Once that has been achieved, the TO becomes irrelevant again. The layout is even less important, since you can GTRR to a TO using ANY layout of the base table.

I think that since you're going to use a script anyway, there's no reason to use a relationship to find the records. However, you need to consider the matter of tagging the exported records. In a multi-user setup, this may fail if another user is editing an exported record.

[Fenton]

This is not so much about "Ugo's method", unless you were going to use it to go further down the relational line, ie., go to another table using the isolated TaskIDs.

There's more than one way to do this. In this case, since all you want to do is to Find these records, probably a plain Find would be best.

Another relational method would be to create an unstored calculation field, text, "Include", then use to match the Status field. That would work for all records (as long as there was a found set). This would be useful if you wanted to see the records in a portal.

Lastly, you could do the above, but use a "constant = 1" field, and match a "include flag" field; similar to above.

TestSelfJoin.fp7.zip

Edited February 3, 2008 by Guest

[Simon K]

Thanks Michael, Fenton

Most helpful

Cheers