GTRR Bug

[David Jondreau]

Go To Related Record in FM9A reports an error code when no error exists.

While using the GTRR script step with Show only and Match all records options checked, if the active record does not have a related record, but other records in the found set do, the correct set of records is found, but error code 101 is reported.

File attached. In the file there are 3 scripts. GTRR 1 and GTRR 2 show correct behavior in various circumstances. GTRR 3 shows the erroneous behavior.

GTRR_Bug_test.fp7.zip

Edited October 2, 2007 by Guest

[Søren Dyhr]

But the cursor resides in a record with no match, which forces the loop to end ... i would like to know when you actualy would need the shown algorithm?

You break out of the looping as soon as a childless record occures, the looping seems obsolete, if you instead changes it into:

Loop 

     If [ IsEmpty(Child:_kf_idParent) ] 

          Omit Record 

     Else 

          Exit Loop If [ 1 ] 

     End If 

End Loop

Will the cursor land in a record which provide a match, and in this case will the 101 error not occure.

However could we by bearing in mind that the first record didn't have a match approach the found set in the opposite direction via Go To Record/Request/Page [Last] initially in your script, but with my modification in the loop. This proves that the 101 only occures if you issue a GTRR(FS) in a matchless record, and NOT if matchless records might occure in the found set.

--sd

[Vaughan]

Soren wrote: "...the 101 only occures if you issue a GTRR(FS) in a matchless record, and NOT if matchless records might occure in the found set."

I think that this could be perceived as a bug: if the "match found set" option is selected the error should only occur if no related records match any master records in the found set, not just the current record.

I've encountered this before and have been looking for a cure. I've never thought of looping through the found set of records and looking for one that has related records.

[Søren Dyhr]

Let's agree here when it's the GTRR(SO) does it make perfect sense to be warned that you still are in the parent layout. But Filemaker is build via object oriented enheritance, to avoid having redundant code laying around in several places, and it's only some of the functions that gets overloaded.

This means that the team behind in thier sloopiness either deliberately have ignored to write an overload or never have seen this as a problem which is likely to occure.

To establish if a found set of records have matching records for a GTRR(FS) Could this CF of JMO's:

Case(



Found > 0;



SerialNumbersTail(

Field; 

Found - 1; 

Result & Case(not IsEmpty(Result); ¶) & GetNthRecord(Field; Found)

);



Result



)

Nicked from here: http://www.filemakerpros.com/GetNthRecordTAIL.zip

...filtered against List( over a cartesian auxillary relation via:

IsEmpty(FilterValues(JMO_CF;List(auxillary::recordID))))

My guess is that it's a tad faster than script looping thru the found set of parent records eventhough tail recursions are a bit slower.

--sd

[David Jondreau]

But the cursor resides in a record with no match, which forces the loop to end ... i would like to know when you actualy would need the shown algorithm?

The scripts in the demo file are purely to demonstrate the conditions of the error I'm talking about. They scripts have no real life implication. Perhaps I should have commented them.

But the situation did arise during real life development in which I had a set of class registrations and wanted to see all the associated payments. Some of the registrations did not have payments associated with them. If the first registration did not I received an error code when there should not have been one.

This proves that the 101 only occures if you issue a GTRR(FS) in a matchless record, and NOT if matchless records might occure in the found set.

Yes, this is my point. No error code should be reported.

It is not a critical bug. But I was error trapping and couldn't figure out why I was getting an error, and wasted about 30 minutes going over the script. And then another 20 making the demo. :)

Edited October 3, 2007 by Guest

[Søren Dyhr]

But the situation did arise during real life development in which I had a set of class registrations and wanted to see all the associated payments. Some of the registrations did not have payments associated with them. If the first registration did not I received an error code when there should not have been one.

But on the other hand does all payments have a registration behind it, so the GTRR(FS) does actually go a pretty hypothetical way here doesn't it??

--sd

[David Jondreau]

But on the other hand does all payments have a registration behind it, so the GTRR(FS) does actually go a pretty hypothetical way here doesn't it??

I don't understand the question, rhetorical or not.

[Søren Dyhr]

It's a question of which is subset of which and why? However is it in order to get the ones who havn't paid is it using all the payments and then a GTRR(FS) from payments instead. When the found set is established is it Show Omitted Only, instead of looping thru every person to establish if he/she really have paid. Unless you establish a unequal relation with a new TO.

--sd

[David Jondreau]

Payments are a subset of Registrations which are a subset of both Classes and Students (Registrations is a join table). I'm quite happy with the GTRR from Class (current record only) to Registrations (all records in found set) to Payments to produce a report of Payments made for a single Class.

I'm not looking to solve a problem, I'm pointing out a potential problem for others.

[Søren Dyhr]

Do you check for raised errorcodes in every script you make? Only real problem I can see is if a previous important set error code gets wiped out, by this probably deliberate object oriented development ommission ...again how often is it likely to occure in real life? As you put it:

the correct set of records is found

...anyway. So you can solve it by comparing the layout name or number before and after the GTRR(FS) ...I would say a $variable comes in handy here. Obviously a little inconvenience to remember - but again how often is it occuring?

--sd

[David Jondreau]

I don't know what a "raised" error code is, but I error trap in most scripts I write. I also run new scripts through the Debugger and have it set to pause on error.

If you're not checking for failed operations, like a failed GTRR or New Record, you should be.

The GTRR script step produces an error code when the operation performs properly. Is that simple to work around? Yes. Should I have to work around it? No.

[Søren Dyhr]

Is that simple to work around? Yes. Should I have to work around it? No

Indeed a good point you make there - But it's a behaviour found in fm8.5 as well, and nobody before you have been making a song and dance about it - to use an English idiom ...it means by the way that fm8 probably had it too.

It is certainly an inconsistency, but I would really like an example where it really matters? If it's when IWP'ing are you already accustomed to several shenanigans anyway... say to shorten the recieved html and similar prerequisites where ingenuity really is king.

--sd

[Ender]

Well, I appreciate you bring this inconsistency to our attention. I haven't stumbled across this myself, but I know I have been using GTRR[Matching Found Set] more and more, so it's good to think about it before the problem arises.

Thanks David! :)

[Søren Dyhr]

I appreciate you bring this

Well actually it's more the spirit I ought to have conveyed here, although:

Shouldn't it perhaps be solved via a separate errorcode, if we ignore IWP scripts stopping for a while. We would need something in between code 101 and 401...

http://www.filemaker.com/help/21a-FMP_error%20codes.html

Something like "some but not all" primary keys have matches???

--sd

[Ender]

Why don't you get on that for us, Soren. :)

[Søren Dyhr]

Ah yes, a quixotic endevour indeed!

--sd