Do you get the same results if you perform the script from a client machine? That'll help tell us if the problem is due to performing it from the server or not.
Replace can be a dangerous tool in shared databases.
Only perform this script on a shared DB when you are sure that you don't have any users locking the records you want to modify with this script step. I'm guessing you're scheduling the script to run at a time when no ones using the DB correct?
If the script fails when you run it from a client machine, you'll need to spell out your table design and relationships so we can help you out.
No, when I run the script(s) in FMP9, everything works normally. I also tried using a loop and SetField, instead of Replace, with the same result. I have the script scheduled to run 3 hours after the backups run, so no one should have any of the databases open.
Also, the account name and password used in the Schedule is the master used in all our databases, so it shouldn't be an access or privilege issue.
Have you checked your script step for server compatibility? That's what tripped me up the first time I tried to use server to perform a script.
Is the layout that is current for your script when you manually perform the script, the same layout that is current when the server performs it?
Be advised that if your file has a script to perform when the file is opened it will automatically perform this script before executing your scheduled script. If so, that script could change what layout is current at the time the scheduled script starts to execute.
Yes, checked for compatibility, and no errors reported in the error log. Here are the only script steps it's using:
Go to Layout
Show all records
Replace Field Contents
So, I have the script going to the layout first, then it starts the Replace. There is a Startup script, which checks the user's account name, for one specific account name, and takes them to a specific layout. What really has me confused is that it works for one table from an EDS, and only that one. Grrr!