I have a script which creates a pair of records ensuring that the first record is always odd numbered (i.e.: it creates one record checks whether its URN is odd numbered and, if not, deletes it and creates another before creating the second half of the pair.

To complicate things the user is given the choice of whether they want a blank pair or a duplicate of the displayed pair.

This works fine in any account (admin or staff) on Server or locally, using FMAdvanced, but breaks when using FMPro (server or local). Without Script Debugger, I'm at a loss as to what it is doing or not doing.

Any thoughts?

What do you mean it "breaks"? Fails to delete the record? Fails to create? Explodes in a ball of flame?

Do you have error trapping OFF so that you see error dialogs as errors occur? You could start there and see what pops up.

Or, turn error trapping ON and then after each script step that you suspect could be failing, write the last error to a log (e.g. a global text field).

The first record of the pair views in a layout called Stage 1, the second in a layout called Stage 2. When this script has failed, clicking 'go to Stage 2' displays the Stage 1 (odd-numbered) record in the Stage 2 layout, from there, clicking 'go to Stage 1' displays a blank record and everything goes pear-shaped from there.

My problem is that it refuses to happen for me. This morning I have tested the script, logged in using an account with the same group privileges as the guys having this problem, using one of their Macs off-site (and therefore FMPro). It behaved itself, working locally and working on the server. I'm having trouble trying to work out how to fix something that ain't (apparently) broke.

I will take up your suggestions re error trapping (why hadn't I thought of that!?)

Thinking about it, that "clicking 'go to Stage 1' displays a blank record" is probably Stage 1 in Find mode (at the moment, I haven't seen this 'breaking', it just hasn't happened in testing).

Slightly more info, than described before...

The first record of the pair views in a layout called Stage 1, the second in a layout called Stage 2. When this script has failed, the first record of the pair is 'even numbered displaying in Stage 1 (i.e.: presumably it has not deleted that record and created another). Clicking 'go to Stage 2' displays the same data in the Stage 2 layout. From there, clicking 'go to Stage 1' finishes in Find mode.

I have several identical accounts including one called 'stafftest' (i.e.: they are all in the same single privilege group) and, when any one staff member is working in his own account, either locally or on the server, the script fails and yet if he logs in as 'stafftest' (using the same Mac) it succeeds.

Is there a global field involved in the script? Global fields are unique to each user in a multiuser application.

Sounds like potential problems with the navigation script as well as your record creation script. Post the scripts and we'll go from there.

I decided that finding the differences between, Macs, accounts and/or FMs was a waste of time. I'll live with the fact that I can't explain why something worked in some accounts and not others.

I've carried out a step by step analysis using error trapping and the Data Viewer and it now works in all accounts.

By way of explanation, at the last minute of development, the client switched from the very limiting unique ID of a single character to two characters and decided to increment the URN from 1 instead of the four figure number in his previous database - that was the cause - I should have realised this would have serious ramifications!

Thank you for your thoughts.