Problem with v7 Script in v10

[T-Square]

My clients are having trouble with a script that I wrote under FM7 that they are trying to run in FM10, and I am completely stumped. The script runs fine on my machine under 7, and it even works for me on FM10 trial version. For my clients, though, the script locks up in an endless loop (but only under 10).

The script (listed below) is supposed to locate the next date whose day name matches the customer's delivery day (which is determined by which site the client gets their deliveries at).

Once the system has found that the days match, it checks to see whether the date is found in a table that lists dates that my client is NOT working (holidays, etc.), and if the date is found there, the script keeps going until the next matching date, at which point it stops, and the date value is set.

The various global fields are set in the calling scripts, and there are records in the SkipDates table (which means that there won't be an error 101 when trying to GTRR). The Delivs - System View is a layout that includes all defined fields for the table.

Unfortunately for my client, this script never stops when they run it under FM10, and it keeps twirling twirling into the future, never stopping for any days. Time keeps on slipping slipping slipping, into the future...

I have verified that the data set being used is valid--and in fact, the same script works fine on the same data under version 7. Can anyone with more experience with FM10 see why this script would work on one machine, but not another?

(BTW, I know this script is brutish, but hey, it works--or did until this)

TIA,

David

------------------------------------

#This macro cycles through to the next delivery date and sets NextDelivery accordingly.

#It uses the delivery day specified for the client's site and delivery schedule.

#Called by:

Delivs - FindNextDelivDate

Delivs - Change DelivToDonee

Set Error Capture [ On ]

#Initialize global counter _g_DelivsWeekCnt

Set Field [ Globals:_g_DelivsWeekCnt; 1 ]

Commit Records/Requests

[ No dialog ]

Go to Layout [ “Delivs - System View” (Delivs) ]

Loop

If [ DayName(Globals::_g_DelivsDelivDate) = GlobalsDelivsSiteID::DelDay /* Days match */ ]

#Now check against skip days

Go to Related Record [ From table: “GlobalsDeliv to Skipdates”; Using layout: ]

[ Show only related records ]

If [ Get(LastError) /* No skip date related to the date found */ ]

Set Field [ Globals::_g_DelivsSkipFound; 0 ]

Else

Set Field [ Globals::_g_DelivsSkipFound; 1 ]

End If

Commit Records/Requests

[ No dialog ]

If [ Globals::_g_DelivsSkipFound = 0 /* The selected date is NOT in Skipdates */ ]

Exit Loop If [ GetAsNumber(Globals::_g_DelivsWeekCnt) >= Globals::_g_PeopleSched ]

Set Field [ Globals::_g_DelivsWeekCnt; Globals::_g_DelivsWeekCnt + 1 ]

End If

End If

Set Field [ Globals::_g_DelivsDelivDate; Globals::_g_DelivsDelivDate + 1 ]

Commit Records/Requests

[ No dialog ]

End Loop

Go to Layout [ original layout ]

[T-Square]

Well, I see that there have been a hundred lookers and not one taker. Oh well. I will sit down at the client's machine in the near future and try to figure out a workaround.

Most likely what I will do is use a value list to establish a dayname/daynum tree, and check for the next available date that uses that daynum.

I am certain that there is no doubt a slick Comment-ish single calculation that will yield the next date to use without all this gnarly looping and comparing.

David

[Vaughan]

Relationships changed slightly between FMP 8.5 and 9.0. From memory, empty keys no longer match to records.

I had a few solutions that broke. Most were fixed by appending a text string onto the end of the keys to ensure they were never empty.

[comment]

It's difficult enough to debug a script by reading only - it's impossible to do so without knowing the context.

• I see a comparison test between two fields - but I don't know what they are.

• I see a GTRR step to test for related records (why is this necessary??!) - but I don't see a return to the originating layout, in case of success.

• Most of all, I see a loop whose Exit Loop If[] is inside an If[] block.

My guess would be that this is not a version issue and that the behavior would be the same in a previous version, given the same data set.

I am certain that there is no doubt a slick Comment-ish single calculation that will yield the next date to use without all this gnarly looping and comparing.

Possibly, but it would require knowing not only the context, but also a better description of the purpose. A simple file, cut down to show only the elements relevant to the issue at hand, would be useful here.

[T-Square]

Vaughan, Comment--

Thank you for your replies. I will examine the situation with these data points in mind. Vaughan, I don't think there are any empty keys in the data, so I don't believe that is the source of my problem.

Comment, I recognize that my original post was dense; I did try to provide context, but clearly I didn't succeed very well.

As further information, the application is a delivery tracking system for farms. The farmers deliver to a set of sites on a given day of the week, which is defined in the site record as a simple text field filled in from a fixed value list of the days of week (that's the GlobalsDelivsSiteID::DelDay variable).

Customers select a site for pickup and their choice of site determines the delivery day. Clients can also choose to have deliveries made every n weeks, which is set in the client record (that's the _g_PeopleSched variable, which is a number field).

Finally, the farm can designate any date as a SkipDate, which is a day on which no deliveries will be made. SkipDates is a table with only one date field SkipDate defined. There is a relationship:

Globals:_g_DelivsDelivDate<=>SkipDates::SkipDate

to handle the GTRR.

The script included is supposed to locate the next date whose:

1) day matches the site delivery day

2) week matches the customer's schedule, and

3) date is NOT in the SkipDates table

"Next date" is additionally defined to be:

1) In the future

2) More than p days from today, where 'p' is a user setting (to allow for a delay in adding deliveries), and

3) After the customer's last delivery

There's more, but I think I'll just try to rewrite the script in a more sane way.

David

[T-Square]

I figure I should close this out.

Comment, you were right to question the GTRR step; it turns out that I was getting an error 414 (Layout can't display result). Combine that situation with a (seemingly minor : ) change in the error test from

"If[Get(LastError) = 101 ..."

to

"If Get(LastError) ...",

and you get a nifty endless loop.

Now, (he says, wiping some egg from his face) Comment, you questioned this step, and I'd love to know how to do this differently. Basically, I was using the GTRR to test for a record that matched the date in the remote file. If there IS a record there, then keep going along, otherwise, you can use this date.

Would it work to have:

If[RemoteTable::DateField ...

and would that work better overall?

Thanks,

David

[comment]

Well sure, it's better to call ahead to see if anybody is home rather than driving out there "on spec". As for the actual test, I don't see your relationship so I can't say for sure, but in general it should be:

If [ not IsEmpty ( Related::Matchfield ) ]

Of course, if the matchfield is a Number/Date/Time/Timestamp, you can shorten it to:

If [ Related::Matchfield ]

Note that this tests the existence of records related to the CURRENT record only. I don't know of an easy test for the current found set.