Script fails on PC and Intel based macs

[gillian]

Hi I have a script that creates a weekly time sheet for a user, collecting all jobs that they worked on the previous week and if the job is still 'open' then it adds it to the list of jobs within their time sheet. This worked perfectly for over a year until we started to add Intel based machines on OS X 10.4 and now PC's, when they perform this script that works well for most on the network it collects EVERY job and often they have to force quit to exit the proecess.

If this script failed completely for everyone I could understand it. They are using version 8 clients, connecting to a version 8 server both with the latest patches.

I have tried new pauses in my script and some extra 'commit record' steps, but am really struggling as to what to try to resolve this, any suggestions would be most welcome.

[Ender]

Maybe you can post the script for us to look at.

[Fenton]

The only time where I think Intel Macs are different is Get ( SystemPlatform ) returns 1, not -1, as it does on PowerPC Macs. So you use Abs ( Get ( SystemPlatform )) = 1 to test for Mac.

[gillian]

My script is as follows:

New Time Sheet

Allow User Abort [ Off ]

Show/Hide Status Area

[ Hide ]

#First set up globals

Go to Layout [ “Time Sheet Entry” (TimeSheet) ]

#NB: Records are sorted on Week Commencing

Sort Records [ Specified Sort Order: TimeSheet::WeekCommencing; ascending ]

[ Restore; No dialog ]

Go to Record/Request/Page

[ Last ]

Set Field [ TimeSheet::glbWeekBeginning; TimeSheet::WeekCommencing ]

Set Field [ TimeSheet::gUserName; TimeSheet::UserName ]

Set Field [ TimeSheet::gNum01; TimeSheet::TimeSheetNo ]

#Now perform find so only one record is showing

Enter Find Mode [ ]

Set Field [ TimeSheet::TimeSheetNo; TimeSheet::gNum01 ]

Perform Find [ ]

Pause/Resume Script [ Duration (seconds) 3 ]

#OK create new time sheet

New Record/Request

Set Field [ TimeSheet::UserName; TimeSheet::gUserName ]

Set Field [ TimeSheet::WeekCommencing; TimeSheet::glbWeekBeginning + 7 ]

Set Field [ TimeSheet::WeekCommencing; Choose(DayOfWeek(TimeSheet::WeekCommencing); "";TimeSheet::WeekCommencing -6; TimeSheet::WeekCommencing; TimeSheet::WeekCommencing

-1; TimeSheet::WeekCommencing -2; TimeSheet::WeekCommencing -3; TimeSheet::WeekCommencing -4; TimeSheet::WeekCommencing -5) ]

Set Field [ TimeSheet::gNum02; TimeSheet::TimeSheetNo ]

#Now duplicate the line items from previous time sheet

Go to Record/Request/Page

[ First ]

Commit Records/Requests

[ Skip data entry validation; No dialog ]

Pause/Resume Script [ Duration (seconds): 3 ]

If [ Count ( tsItems::Job_No) ≥ 1 ]

Go to Related Record [ From table: “tsItems”; Using layout: “PurchaseOrders” (PurchaseOrders) ]

[ Show only related records ]

Pause/Resume Script [ Duration (seconds): 1 ]

Perform Script [ “Duplicate line items” ]

Select Window [ Current Window ]

#Added 2.12.03 to correct rates not pulling through

Go to Related Record [ From table: “tsItems”; Using layout: “PurchaseOrders” (PurchaseOrders) ]

[ Show only related records ]

Perform Script [ “Relookup client rates” from file: “CJC_If” ]

Pause/Resume Script [ Duration (seconds): 3 ]

#Amend complete

End If

The other scripts that this one calls are:

Duplicate line items

Enter Browse Mode

Go to Layout [ “All fields - tsItems” (tsItems) ]

Go to Record/Request/Page

[ First ]

Loop

If [ PatternCount(Jobs::Job Status;"Job Completed") < 1 ]

If [ not IsEmpty(tsItems::hrsMon) or

not IsEmpty(tsItems::hrsTue) or

not IsEmpty(tsItems::hrsWed) or

not IsEmpty(tsItems::hrsThu) or

not IsEmpty(tsItems::hrsFri) or

not IsEmpty(tsItems::hrsSat) or

not IsEmpty(tsItems::hrsSun) or IsEmpty(tsItems::Client_ID) ]

Duplicate Record/Request

Set Field [ tsItems::TS_No_Client; TimeSheet_tsItems.SysConstant::gNum02 ]

Clear [ tsItems::hrsMon ]

[ Select ]

Clear [ tsItems::hrsTue ]

[ Select ]

Clear [ tsItems::hrsWed ]

[ Select ]

Clear [ tsItems::hrsThu ]

[ Select ]

Clear [ tsItems::hrsFri ]

[ Select ]

Clear [ tsItems::hrsSat ]

[ Select ]

Clear [ tsItems::hrsSun ]

[ Select ]

Clear [ tsItems::Internal_rate_override ]

[ Select ]

Clear [ tsItems::Client_rate_override ]

[ Select ]

Set Field [ tsItems::Status; "In Progress" ]

Omit Record

End If

Go to Record/Request/Page

[ First ]

Omit Record

Else

Omit Record

End If

Exit Loop If [ Get(FoundCount) < 1 ]

End Loop

Go to Layout [ “User view” (tsItems) ]

Relookup client rates

Allow User Abort [ Off ]

Enter Browse Mode

Go to Layout [ “All Jobs report - Plus tsItems list” (tsItems) ]

Go to Field [ tsItems::Cat_ID ]

Relookup Field Contents [ tsItems::Cat_ID ]

[ No dialog ]

Go to Field [ tsItems::Client_ID ]

Relookup Field Contents [ tsItems::Client_ID ]

[ No dialog ]

Go to Layout [ “User view” (tsItems) ]

I hope that this helps. Many thanks

[Ender]

Sorry gillian, I don't see why it would run differently. Other than the case Fenton mentioned, I only remember seeing behavior of script execution due to plug-ins not working with the Intel Mac. And it doesn't appear that your script uses plug-ins.

...it collects EVERY job and often they have to force quit to exit the proecess.

It sounds like the problem is with the Go to Related Record[] step or the Loop failing to exit.

Maybe there's a problem with this:

Go to Related Record [ From table: “tsItems”; Using layout: “PurchaseOrders” (PurchaseOrders) ; Show only related records ]

If that's an accurate transcription, then the tsItems TO is not the same as the PurchaseOrders TO. The subscript then starts by switching back to the "All fields - tsItems" layout, which is based on the tsItems TO. Since the GTRR's layout and the "All fields - tsItems" layout are based on different TOs, the found sets are not necessarily the same (each TO has its own found set).

Maybe the reason it works in the PowerPC platform has to do with a previous script that branches according to the get(systemplatform) step, setting the found set in the tsItems TO.

You might stop execution at the start of the subscript (before and after the Go to Layout) and check the found sets. See if my theory fits.

[Søren Dyhr]

A detail regarding the script, that doesn't have anything to do with the platform, is catching my attention - when you write:

If [ not IsEmpty(tsItems::hrsMon) or

not IsEmpty(tsItems::hrsTue) or

not IsEmpty(tsItems::hrsWed) or

not IsEmpty(tsItems::hrsThu) or

not IsEmpty(tsItems::hrsFri) or

not IsEmpty(tsItems::hrsSat) or

not IsEmpty(tsItems::hrsSun) or IsEmpty(tsItems::Client_I D) ]

Could it easier be written this way:

If(Count(

tsItems::hrsMon;

tsItems::hrsTue;

tsItems::hrsWed;

tsItems::hrsThu;

tsItems::hrsFri;

tsItems::hrsSat;

tsItems::hrsSun;

tsItems::Client_I D)]

As well as I would lead your attention to this:

http://fmcollective.com/?p=27

This means that I'm not sure I would keep these fields in the same table as individual fields, but instead break it out in a related table with 3-4 fields, incl. the foreignkey.

tsItems::hrsMon;

tsItems::hrsTue;

tsItems::hrsWed;

tsItems::hrsThu;

tsItems::hrsFri;

tsItems::hrsSat;

tsItems::hrsSun

...I would probably break them out with one of these two approach in mind:

http://www.fmforums.com/forum/showpost.php?post/205259/

...chosing the one with the cartesian relation and the global that controls the calc' that points at the related.

But that's another matter from which you, probably later will base you design on. Back to you scripting - where there is this:

Set Field [ TimeSheet::gNum01; TimeSheet::TimeSheetNo ]

#Now perform find so only one record is showing

Enter Find Mode [ ]

Set Field [ TimeSheet::TimeSheetNo; TimeSheet::gNum01 ]

Perform Find [ ]

Show All Records

Omit

Show Omitted

It does the same.... and the first line can be avoided if we not allready deals with a found set.

Next thing I stumble over is this:

Set Field [ TimeSheet::WeekCommencing ; TimeSheet::glbWeekBeginning + 7 ]

Set Field [ TimeSheet::WeekCommencing ; Choose(DayOfWeek(TimeShee t::WeekCommencing); "";TimeSheet::WeekCommenc ing -6; TimeSheet::WeekCommencing ; TimeSheet::WeekCommencing

-1; TimeSheet::WeekCommencing -2; TimeSheet::WeekCommencing -3; TimeSheet::WeekCommencing -4; TimeSheet::WeekCommencing -5) ]

...could be done this way:

Set Field [ TimeSheet::WeekCommencing ; TimeSheet::glbWeekBeginni ng - DayOfWeek ( TimeSheet::glbWeekBeginni ng )+9]

Then is there the looping in the portal rows, you issue way to many omits by persistenly going to first record, if you start you loop in the buttom, will a duplication be followed by two separate omits, making you ready to test the last record in the found set, if the condition isn't met, the issue just one omit.

But then are we at the next problem, is ratio of suviving fields vs the cleared really in favour for the Duplicate, wouldn't it be better to - make the few fields autoenter "value from last visited record" or the global field in a autoenter calc' ...via a New Record/Request.

What you here have exhibited, isn't the strongest scripting skill's seen, but what's worse is that you give yourself away revealing a poorly thought out realtional structure, which are likely to require comprehensive but unessersary scripting.

--sd

Edited June 19, 2007 by Guest

[gillian]

Thank you for your thoughts on my scripting, I will certainly look at your comments and see if I can improve the script. Perhaps you feel my tables are not well thought out as you are only seeing a tiny part of the solution, but I will none-the-less take on board your comments.

It is always the way, that the moment I post a problem, my last attempt at a fix resolves the issue.

The pauses of 3 seconds and extra record commits seem to have sorted this problem out - it is as though the PC's and Intel Mac's process too fast, so slowing them down has improved the situation.

Thank you to all that have commented.

[Søren Dyhr]

Perhaps you feel my tables are not well thought out as you are only seeing a tiny part of the solution, but I will none-the-less take on board your comments.

I'm glad you didn't take it too offending - On earlier versions was a "gynecologist" approach sometimes required to prevent changes to both relational structure and fields, so much more were likely to get scripted (and even applescripted on macs)

....much more than required today where you can approach your data via the separation model ...building you own ad hoc relational structure as well as the scripting only needs to be established in the interface file next to you.

Similar have the max 50 table approach form earlier versions evaporated into thin air. So all in all would I say - solve as many of the issues relational and then later seek shelter under scripting ...the last argument isn't a particular filemaker'ish issue, it's an omni present truth - poorly structured solutions requires at lot more scripting!

You should indeed take a look at the calendaring threads download (I would prefere you read the thread) or alternatively see if you get the gist of this template where each filled field is a record on it's own ...there is no need to make records ahead of time if they needn't get filled ...well the download here is made as an alternative to David Kachels tiered tables, and is not aiming at your problem in particular. But see if you get the idea. Petrowski calls it...

http://www.filemakermagazine.com/videos/data-tagging-classification-vs-organization.html

The reaason why Kachels approach lacks a little to be desired is due to the number of indexes that works, he have one for each required related field. But read about his tiered tables approach in his whitepaper. The JMO apporach from the calendaring thread is blinding fast due to simplicity of his graph!

--sd

ContactsSD.zip

[gillian]

I will definitely check this stuff out - the reason that there is so much scripting is that it was previously a version 5 solution. While it was restructured into version 7 at the time the majority was simply to get it into two files, interface and data; now I see that probably I should look to incorporate so much more!

Thank you

[Søren Dyhr]

the reason that there is so much scripting is that it was previously a version 5 solution

Only! It isn't quite true - In my humble opinion is it still due to an inadequate structure.

I've meanwhile toyed with the idea ...it's very posible today sans any scripting, while I admit that earlier was setting the global field to mondays only - a single line of script. Now I do in the template utilize 5 multi-criteria relations, and the new fm7'ish tunneling of related data from more than a relation away.

Multicriteria relations was previously made by concatenating the keys into one separated by a | (pipe) or similar. While the tunneling needs a unstored calc'field showing the related value from more than one relation away - but the settin of the value needed a tiny GTRR and a pause, until entry was made and the user was returned to the portalview ...again a very very tiny script!

But as such will you by investigating the attached template, recognize that your extensive scripting now as well as previously weren't required at all. While it as well previously urged for some tiny scripts to set the data in the correct positions in the portalrow, have this need dissapered from fm7 and beyond!

I have found good use of Edoshins "Smart Ranges" since my view should should show every event overlapping the view dates, which is a OR'ish relation, while the standard setup with multi-criterias is AND'ish.

http://www.onegasoft.com/tools/smartranges/index.shtml

...I found it easier to copy and paste the calc's than wrecking my brains with Demorgan'ing the expression to abide with these limitations. The use of a repeating calc' could be utilized, if not you needed to reserve repeating enough to deal with open upper ranges ...as it is must SmartRanges be easier to index, and by it put less strain on the calc' engine???

What is missing, a valiation that prevents to orphan records when establishing an upper range ...I'm still thinking of a way to make it work - But it's probably something with Max( and an extra TO ...any ideas?? Similar could be said about the Calc'fields they could benefit from being Let('ed or CF'ed ...in order to evaluate faster. Finally should some craftyness prevent saturdays to turn up a portal line, which looks foolish to say the least, when you can't enter anything.

--sd

scriptLess.zip