The error message means that filemaker couldn't create the file so something is preventing that from working.
Check to make sure that with the windows 7 upgrade you still have "write" privileges on the remote location to which your script is attempting to save a file. As a test, you might try just opening the directory and copying a file to it using just windows 7 to do so.
Thanks for replying to the post. I believe I do have 'write' privileges still because I am still able to save files into the directory from the other computers on the network.
Something that I forgot to mention in the previous post is that while I am not able to save .pdf using the script that was in place, I have the ability to save .pdf through the File->Print->Bullzip PDF funtion within Filemaker. What that leads me to believe is that FM is interacting with the remote file to 'save' files, but the script cannot interact with it.
Can you do this with the Save As | PDF option in the File Menu?
What you report suggests that write permissions are not the issue.
I'd then take a look at the exact file path specified in your script and compare it to the actual file path from the Windows 7 computer to this shared directory. I know you say it hasn't changed, but I can conceive of no other explanation that fits here--other than saving to a disk that does not have sufficient free space and that would prevent "printing" a PDF to this location as well.
Yeah Ill have a closer look at the filepath comparisons to make sure they are the same.
This issue is perplexing me because I've searched this forum inside and out, as well as other web destinations, for an answer but yet to find one. Very weird.
You could create a pdf in the destination folder, then copy the file path as shown in Explorer when you navigate to that file. Hard code that into the script 'Save as...' line and temporarily replace the (presumably) variable pathname. If it works then you have a pathname problem. I think that the error message starts with ".pdf could not [etc]" suggests that also.
Every time I have had that error it has been a pathname problem.
You can also set the pathname into a global field just after the script finishes, then copy and paste it into an Explorer window (on one of the 'non-working' machines) and see if that opens the folder you expect.
You can also manually insert a file located in your shared directory with the store as reference option selected into a container field, then use getastext( containerField ) to examine the file path entered into the container field to compare it to what you are using in your Save As PDF step.
I've recehcke the filepath to the remote file and everything is consistant. I gave it another go and up pops the same error message. The mystery continues.
I still suspect its a Windows realted issue, not Filemaker. Since the host computer can utilize the script and save it as it should be save, it has something to do with the other computers in the office and their settings with realtion to the host computer.
While not doubting your conclusion, I question your logic for it: "Since the host computer can utilize the script and save it as it should be save, it has something to do with the other computers in the office and their settings with relation to the host computer". A flaw in the pathname will produce exactly this problem.
Did the setup 'pass' all the suggested tests? Hard coding? Copying and pasting into Explorer? Insert a test file, use GetAsText, copy and paste that pathname as hard-code into the script?