Local vs Server - Different outcome for script

[fishtech]

I am having a problem with a relatively simple looping script. The script checks employee totals for a month; values above a certain amount for an employee are carried forward to the next month.

The script runs PERFECTLY when it is local.

But when the files are moved to the server and run over the network, incorrect results are often (but not always) returned. In fact different results are often returned when the script is run on identical data-sets just a few seconds apart.

Correct results are always returned the FIRST time this script is run over the network. Subsequently, incorrect results may or may not be returned.

I have tried placing 'commit' steps in many different places without success.

I have deleted all caches on the client machine, and have saved compressed files for the server.

It seems that some kind of network/processor lag is causing this script not to work correctly between client<>server. But I would love someone to point out some error in my script that is creating the inconsistent results.

Thanks,

ft.

Set Error Capture [ On ]

Go to Layout [ “InfractionTracker” (InfractionTracker) ]

Loop

Perform Find [ Specified Find Requests: Find Records; Criteria: InfractionTracker::MonthlyBalance: “<0” AND InfractionTracker:: Reconciled: “=” AND InfractionTracker::CarriedForward: “=” ] [ Restore ]

Exit Loop If [ Get(LastError)=401 ]

#Check for duplicates for employee for month

If [ Get(FoundCount)>1 ]

Sort Records [ Specified Sort Order: InfractionTracker::Employee#; ascending InfractionTracker::dAppliedFirstOfMonth; ascending ] [ Restore; No dialog ]

Go to Record/Request/Page [ First ]

Loop

Set Variable [ $checker; Value:InfractionTracker::Employee# & " " & InfractionTracker::dAppliedFirstOfMonth ]

Go to Record/Request/Page [ Next; Exit after last ]

#Exit loop when all duplicates for employee for month have been marked

Exit Loop If [ $checker <> InfractionTracker::Employee# & " " & InfractionTracker::dAppliedFirstOfMonth ]

Set Field [ InfractionTracker::Reconciled; "x" ]

End Loop

End If

Go to Record/Request/Page [ First ]

Duplicate Record/Request

Set Field [ InfractionTracker::Details; "Brought forward from " & InfractionTracker::dAppliedFirstOfMonth ]

Set Field [ InfractionTracker::AmountFined; Abs(InfractionTracker::MonthlyBalance) ]

Set Field [ InfractionTracker::dAppliedFirstOfMonth; Date(Month(InfractionTracker::dAppliedFirstOfMonth)+1; Day(InfractionTracker:: dAppliedFirstOfMonth); Year(InfractionTracker::dAppliedFirstOfMonth)) ]

Set Field [ InfractionTracker::InfractionNumber; "" ]

Go to Record/Request/Page [ First ]

Set Field [ InfractionTracker::Reconciled; "x" ]

Set Field [ InfractionTracker::CarriedForward; "x" ]

End Loop

Edited February 26, 2008 by Guest
Trying to make script easier to read

[LaRetta]

Hi fishtech,

Well, I read your script and re-read it. I still can't understand why you have structured your script as you have. Why do you have your find within a loop?

Well, anyway, you are marking records. Since it works stand-alone but not when served, I would suspect that some records are locked and you cannot mark (flag) them. Also, you test if number of records is greater than 1 and then proceed. But if only one record, that record will NEVER get addressed (or flagged) anywhere in your process (that I can tell).

If you MUST flag records (and I believe that sometimes it must happen in the best of systems (even if it's just setting records with a Posted date) then either trap/re-check heavily or run process at night when nobody can possibly be in the system.

[fishtech]

Hi,

Many thanks for your consideration. The system I am trying to create is a portion of a personnel database as follows:

- Each employee receives a monthly bonus.

- Each time an employee does something wrong (an infraction), a dollar amount is deducted from their bonus

– If deductions in any month are greater than the bonus amount for that month, the balance is carried forward to the next month until it is paid.

- If an employee make a serious infraction they may be placed on probation for 30, 60, 90 or 120 days. Whilst on probation an employee receives no bonus.

- Whilst on probation an employee can accrue further deductions from bonus for further infractions.

Example1:

Bob has a $100 monthly bonus.

In January he is deducted $25 for tardiness.

His January bonus is $75.

Example2:

Jane has a $100 monthly bonus.

In February she is placed on probation for 90 days for a major misdemeanor and so she reveives no bonus for Feb, March, April.

In March she causes $500 worth damage to company equipment.

The $500 is carried forward and deducted from her bonus in May, June, July, August and September.

I still can't understand why you have structured your script as you have. Why do you have your find within a loop?

If this can be done in a more efficient way I would be happy to change the script.

The main loop does this:

start loop

1. Find unmarked infractions with a negative monthly balance

2. Check to see if there are other infractions for the same employee for the same month. If so, they are marked.

3. Duplicate & marks the first infraction record

4. Adds '1' to the month-of-infraction of record created in step 3 to carry the balance forward in time until it is positive.

end loop

I would suspect that some records are locked and you cannot mark (flag) them

That would be a good idea except I am the only user with these files open. I have full admin privileges on the files.

When I first open the file the script takes about 4 seconds to run and works perfectly.

Subsequently it sometimes works perfectly and sometimes screws up, carrying balances forward multiple times.

if only one record, that record will NEVER get addressed (or flagged) anywhere in your process (that I can tell)

That is not correct. The last 2 lines before the final 'End loop' will mark a single record.

trap/re-check heavily or run process at night when nobody can possibly be in the system

As mentioned, I am the only person logged onto the files.

I have done as much trapping as I can think of. If I step through the file using 'debug Scripts' Advanced the script always works perfectly.

It works perfectly the first time it is run over the network.

Thanks again,

ft.

[LaRetta]

Then all that is left to suggest is posting the file. I cannot suggest how to restructure the script specfically, and I can't pinpoint the error, when I do not have the full solution from which to test.

Maybe others can see the problem. But I would NOT have the find within the loop because you are finding a new set each time and, well, it makes no sense to me.

[fishtech]

I have been able to get the script to perform consistently by placing a 0.5 second pause script step after the first find.

A 0.1 second pause is not long enough.

I really don't get this...

ft.

[Vaughan]

"I have been able to get the script to perform consistently by placing a 0.5 second pause script step after the first find. A 0.1 second pause is not long enough."

That's interesting... I didn't know the pause step could work with fractions of seconds; sounds like some kind of voodoo happening.

Most times I've seen where a script works "better" with a pause, it's been a case where records are not committed.

Regarding record locking (from an earlier post): it matters not what privileges the user has, or how many users there are: if a record is open in a window, it'll be locked in all other windows even for the same user.