We'd need to see your script.
To post a script to the forum:
- You can upload a screen shot of your script by using the Upload an Image controls located just below Post A Answer.
- You can print a script to a PDF, open the PDF and then select and copy the script as text from the opened PDF to your clipboard for pasting here.
- If You have FileMaker advanced, you can generate a database design report and copy the script as text from there.
- If you paste a text form of the script, you can use the Script Pretty box in the Known Bugs List database to paste a version that is single spaced and indented for a more professional and easier to read format. (Use the HTML option on the database tab panel and paste the text into the forum's HTML editor.)
The script that is causing the problem had been working w/o any problems for a few weeks, before I added the 'If [weights="" script step to run the form check script when data was entered into the first cell of the repeating field. The error appears at the Commit step
Set Variable [ $Count; Value:anode cross::wires used + 1 ]
Set Field[ anode cross::wires used; $Count ]
If [ inspectiondata::weights="" ]
Perform Script [ “pressing check” ]
The last step of this script: Commit Records, will change the field focus. The "Pressing check" script might also be a factor, but you haven't posted it so I can't know if that might or might not be the case.
I didn't know why changing the field focus would matter, the documentation commit doesn't say anything about changing focus, but it does make sense that it would. It is odd that it changes focus before the data is stored in the field that is being committed. I removed the commit, and the problem went away. So apparently I shouldn't be committing a repeating field until I've finished filling it.
Commit record closes the current record and saves the changes. This also removes the cursor from any field that had the focus.
To quote from the help file:
"This script step exits the current record or find request, updating field data and making no field active."
If, for some reason, you need to commit the record as part of this script, you can use go to field after the commit record step to put the cursor back into the field.
Sorry, I had read the 'Commit Records/Requests' help topic 3 times today, and several times previously, before I saw this! You are providing the best help I have received for any software. Thank-you.
Now there is a new wrinkle. We have six operators using the same layout to record weights, all in different records. But one operator (D3) is getting a message that another operator (D2) is modifying his record, and he can't use it, but records the new weight anyway. But it is a nuisance, as he has to press ok on the computer to continue. He is not on the same record. If I go into his record from my computer, I get the same message, but twice, once that D3 is using it and once that D2 is using it, and I can't record a value.
I tried committing after each weight is stored, but 'goto previous field' afterwards does not return to the next empty cell in the repeating field as our users expect.
We don't display RecordID on any layout, and it won't be convenient to do so until all our users are offline later today. Is it possible for two different records to have the same RecordID? But even that doesn't fit, as then D2 would be having the same problem as D3 and she doesn't.
'goto previous field' afterwards does not return to the next empty cell in the repeating field as our users expect.
Shouldn't you use go to NEXT field? That should move you to the next field in the tab order which I would expect to the next repetition in your repeating field. That said, I suggest you work towards eliminating the use of repeating fields as there are almost always more flexible ways to enter and work with your data by using a related table of records instead of a repeating field.
Edit locks on records can be a challenge to figure out. Are there any fields from related records located on your layout? Does D2 have just one window open or more than one? Any other scripts being performed?
Record ID's--the value returned by Get ( RecordID ) is unique in your table--there won't be any duplication, so I doubt that's the issue. Instead, some other action by one of the two users is briefly encountering an edit lock on a record.
Sorry again. That last problem was caused by the script step:
Set Field[ anode cross::wires used; $Count ]
Both D2 and D3 were on different pressing records, but this step was updating the same record in anode cross. Too bad FM doesn't report the table that the conflict is occuring in. And if I had used the script debugger I would have noticed where the problem was.