(Current environment is iMac runnig 10.2.8) In FM5 I used relationships between a new entry global field and text fields as dupchecks: "DupcheckName" gName to NameField within the same file. The subscript before using setfields to copy data from the global fields to text fields in a new record field was:

Go related record "DupcheckName", show only related records

If Status(found count) >0 {(get(found count) in FM7)}

Dialogue: "this is a duplicate entry"

Halt script.

End if

In FM7, this does not seem to work. I used the commit records step previously suggested without success. After a lot of experimentation I have discovered the following.

The layout for the go to related record needs a List layout showing the records. It doesn't seem to work in my new entry layout with just global fields; (Also, it doesn't seem to work with Current Layout or the New Entry layout selected).

If there is a match (ie. there is a duplicate entry) the user is taken to the layout with the records but not if there is no match.

The found count will show the number of matcing records but if there are no matching records the found count will list the number of records showing (not omitted) that were present before the script ran. (In FM5 the found count would go to zero if there were no matches.)

To test the relationship, I put a portal on the new entry layout and the relationship did indead work. Interestingly if any matching records were omitted from the showing collection, the relationship and portal also omitted them. Thus if there was a match in the file, but not in the showing collection of records, the portal did not recognize it. Instead of being a relationship to all the records in the file, it was a relationship to only those showing.

It should be known that all this goes on in the same window, if that makes any difference.

Help. I would like to continue using the relationship as a dupchck because it is so simple to script, but if there is none, I will have to use "finds" that require more script steps (slower) or find how to use the new FM7 find criteria box (which I find a bit hard to master as yet.

Why not test for the validity of related items instead of 'going' to them?

If [Length( DupcheckName::serial )]

Message...

Halt Script

End If

The bug in FM7's GTRR has been discussed in other threads, I would suspect this will start working correctly again in the future.

Queue,

That's really elegant! ... it gets around the problem of being bounced back to the found set if there are not related records...

But given what Oldsneekers says, probably there will still be some trouble here too: the relationship was working only between the global and any records matching that value in the FOUND set. Yet it needs to pull any dupicate. Of course, a "show all records" step in the script ought to solve that problem...

Meanwhile, I'm still curious what would account for Oldsneeker's relating-only-to-found phenomenon. When I set up a global-to-text relation, it reaches into the omitted set without any trouble...

:

The "bug" cited by Shadow is NOT a bug. It is new, deliberate behavior of FM7 and we all need to plan accordingly. Also, the preferred test for existence of a related record is isEmpty(), which FMI has optimized for performance for this purpose.

If [isEmpty( DupcheckName::serial )]

Message...

Halt Script

End If

Although in this case, you would use not IsEmpty( ). I just prefer using Length( ) instead of negating IsEmpty( ).

BruceR said...The "bug" cited by Shadow is NOT a bug. It is new, deliberate behavior of FM7

So sure are you? I suggest that once the FM7 Updaters start being released, you check this out again. This is bad behavior and, as The Shadow indicated, isn't what it should be doing ...

I always considered Length(XXX) to be for text length and not record count. I will give Queue's suggestion a try. Thanks.

Up to date on experiences: the portal relationship to only to the found count was using match fields which included a concatonated calc field (NameA &"PP"& NameB in the related record and a concatonated calc field from globals in the main record). Though both name fields and the calc field were indexed (in the related file) the relationship worked only to the found records. When I changed the match fields using NameA and Name B in stead of the calc field (to the respective global fields in the main record), the relationship behavior changed to include all the records in the file (found and not found). Eureka.

Another "quirk": I have a match field (calc field) that takes the first left letter of a name, then &"PP"& then the 2 left letters, then &"PP"& then the left 3 letters and so forth to 5 or 6 and then the full name so that the portal can act somewhat with clairvoiance. The origin side of the relationship is a global field into which the user inserts the letter or letters and clicks on the matching portal entry to populate a field. This works great in the file where all the name records reside. When I do this in another file, the the portal does not respond to the letter entries until I go from brows to layout mode or, while in brows mode, leave the record momentarily then back to the original record. I put a command "commit records" on a nearby button (not a desired feature but to use as a test) and this did not help. What could be going on here?

I guess I've been working with FM5 too long and got complacent.

"It's never so bad that it couln'd get worse."

Yes, I'm sure. That's what FMI has declared in other forums. But it has been the subject of much contention, and perhaps they will change their mind. I don't have access to the update beta files.

Length wouldn't be used for record count. But in this case, you only need to know that there is at least one related record, not specifically how many there may be. So if Length is anything other than zero, you know there is one or more related records and the test returns true.

So sure are you? I suggest that once the FM7 Updaters start being released, you check this out again. This is bad behavior and, as The Shadow indicated, isn't what it should be doing ...

Shadow is misinformed. The 7.02 update is out and this behavior has not changed. FMI announced that this is the new behavior of GTRR, so get used to it. GTRR won't do anything - won't even switch layouts - if there are no related records to go to. The found set will not be changed and you will not end up with a found set of zero if there is no match.