Odd. I have seen this happen if certain things are being watched in the Data Viewer, but does not seem to be the case here.
Can you share your script?
The script is a fairly big one, 331 lines, and 9 pages when printed to pdf.... The first 190 lines are a bunch of business logic to check for liquor products on the order and move them to a new order if found. I'm hesitant to share the entire script since I signed a bunch of stuff when I started working with them...
Here's a screenshot of the part that loops over the line items. If there's a problem, I assume it's in this part, but it's really a very simple script. I see no way for the line item quantity to change.
The joy of inheriting a database someone else created! I've spent hours refactoring this script, adding comments, and white space to make it more understandable and perform better. At first I thought there was just a dumb mistake somewhere, but I've been through every line of code several times looking for any way this could be happening. At this point all I can imagine is it must be a bug in filemaker, or corruption in the database file.
are their any trigggers that fire on commit?
Check your script at line 214
There is a global variable $$disableScriptTriggers that is set at the beginning of the script. All script trigger scripts check for that global variable and "exit script" if it's set. I double checked, and they are all exiting properly.
The subscript on line 214 was added as a bit of a hack for one product that they wanted to replace with another product when it ran out of stock, and keep the same profit margin on it. That usually wont run, but here's a screenshot of the subscript.
Have you checked the pertinent fields to make sure there have been no previous data entry errors? The easiest way is to go into Find Mode on your line items layout and in those fields do an Insert from Index so you can see all the entries for the field.
Do you have any plugins installed? EventScript, perchance? Anything else?
"Every once in a while, maybe one out of a thousand line items, the quantity on the line item will change to a different number." How do you identify this line item, as far as it changing? Do you know the "original" value, and the "new" value? If you change just the value back to its original value and then re-run the script, does it change in exactly the same way?
At line 214, you appear to be running a Perform Script on Server script, "[subscript].replace autopurchase products". The script is run only when $new_stock is <= 0. Are THOSE the records that are changing when you don't expect them to? In the Perform Script on Server, is the script absolutely correctly recreating the environment so that the same record is being found where you've checked to see if T12j1a_invoices_Products||productNumber::Amount_in_Stock is <=0? We need to see that script, I think.
No plugins. Confirmed it's not a data entry error. This has been going on for a few weeks now.
I may have been wrong about where the data is changing though. Now I'm pretty sure the quantities have already changed by the time it gets to looping over the line items.
The data must be changing when it's imported from FileMaker Go into the server.
Has anyone ever seen data change when importing before?
Have you done control exports to CSV in FMGo to compare the data before and after import?
It really is a matter of tracking the issue down. Seems like you are doing a good job.
I have never seen data change on import.
The only time I have seen data change on import is if there are auto-enter entries on fields and the "perform automatic updates" box is checked on Import Records. Any of that possible?
Data changes very time I import! If it doesn't, what's the point??
But I suppose that's not what you mean...
There's a few things that it could be. Is the bad data the old quantity that doesn't get updated? What happens if the record is in use by another user? How is the import being conducted? Just using the Import script step or through third-party syncing?