Basically I need a field that will be used as a trigger for other events. I need a field (a date, number text, anything) that will have data that will change in some way anytime a new portal row is created or changes are made to a portal row.

As an example: Count(Related::One)

Counts the number of portal rows, and changes for each new addition or deletion.

But for my purposes I need a field that will indicate changes that IS NOT based on a relationship. This field is being used in such a way that anytime the data in the field changes it triggers another event, but if the field is based on a calc that uses a relationship it wont work for my trigger setup.

I am trying to keep it simple and dont want to use scripts. So does anyone have any ideasof any type of field I can use in my database (that does not use a calc based on a relationship) that will have any kind of data that will change when a portal row changes?

LR

This seems like your basic overly constrained problem. If solutions can't use related field or script, I'm not sure I see any way of communicating between files without related fields. Without script, approaches that perform scripted checks are out.

If you want a solution, you will need to rethink your total design or relieve some of the constraints on a solution.

-bd

I figured that was going to be the case. Here is why I asked the question in the first place. I have a portal. In the main file I also have a field that summarizes one of the fields in the portal using the following manner:

ValueListItems("Trigger.fp5", "Test") & Left("",Count(Trigger 2::ID))

This partucular field using the above calc works great to summarize my field in the portal. The Left("",Count(Trigger 2::ID)) portion of the calc is necessary to make it stay current. It makes it update anytime the portal information changes. If I have 3 name entries in the portal, then my above calc summarizes and gives me:

Larry

John

Charlie

But since the above portion of the calc Left("",Count(Trigger 2::ID)) is based on a relationship, the calc results cant be indexed or stored. So I figured that if I could point this portion of the code to some sort of field in my main database that was not related (a field that would somehow have information in it that would change anytime a change was made to the poral), then I could index/store the calc results, thus allowing me to use it in another value list in another related database file.

LR

You can create a lookup field that looks up the value of the calculated field. You need to create a selfjoin relationship based on a unique ID field so that the lookup field will lookup the value from its own record. You also need to make something trigger the lookup. This is the same idea as the audit trail trigger technique.

MyTriggerField = MyUniqueIDField & case(SomeTriggerField,"","")

Then your selfjoin relationship would be

MyUniqueIDField<->MyTriggerField

I follow what you are saying. I have been working on something similar. Here is what I have so far in my main database:

A text field called "Time" that is set to auto entry time modified

A text field called "Name"

A self join relationship called Value based on cTrigger->Record ID

A portal using a relationship called Similars based on Record ID<->Similar

A field called Summary with a calc that summarizes the text field "Name" and also summarizes any names contained in the portal:

If( not IsEmpty(Name), Name & "

Are you sure Summary2 need to be indexed? Or are you just displaying it? Try making Summary2 an unstored calculated field with this formula:

File1::Summary

If I set Summary 2 to a calc and use File1::Summary, It then contains the contents of Summary.

My ULTIMATE problem is that I am trying to get the results of Summary to be able to be used in a value list. Summary cant be indexed, so I cant use it in a value list. That is shy I am trying to figure out a way to have Summary 2 be indexable and somehow contain the same info that Summary contains, and then I could use Summary 2 in a value list.

LR

You need to create a trigger calculation field in the file where Summary2 exists.

TriggerCalcField = MyUniqueRecordID & Case(count(relatedfile::anyfield),"","")

and an unstored calc field:

cSummary = relatedfile::Summary

a selfjoin relationship between MyUniqueRecordID <-> TriggerCalcField

Then make summary2 a lookup from field cSummary based on the selfjoin relationship.

This was rather quick. Hope I didn't miss anything.

Whoa. Hold on just a minute. Are you saying that you just want to create a value list in the second file based on the values in the portal from the first file? Then, just set up a value list from the second file based on related values using a relationship to the first file.