The one change I made when installing FMS v15 was to change the server name. I just discovered many users have been using the Open Recents option under the File Menu and selecting the Priority Express database with the old server name.
It's quite possible this is why the import script step is requesting the database be opened. Will update later today after more testing.
You can make sure the file references are to the new server name (domain name?). you have found the "File Path List" dialog. and it is perfectly legal to have more than one reference to the same file. I recommend checking all Specify File references.
All users cleared the list of databases from Open Recents in the File menu and closed FileMaker. They then reopened FileMaker and the Priority Express database from Hosts in the Launch Center. So far, any script with an import script step has run correctly for all users.
I think I can confirm the bug was caused by users choosing the Priority Express database with the old server name in the Open Recents list. FileMaker was able to open the database but internally when a script ran and reached the import step it acted as if the database selected in specify data source was not open even though it was.
The problem is with FileMaker's easy to use point and click and a while back FileMaker finally offered a fix.
set var $file to get(filename)
in the dialog use $file instead of browsing for a file.
When you point and click on a file in the file browser, you are hard wiring the location of that file just as if you address a post card to someone . If that someone moves, then...
Using the variable you let FileMaker lookup itself and then use that info in the dialog. It's all fresh, etc.
I ran into this with a new client when I moved the files off of a host who was not so good and in house. That host alos ran into the problem but did not fix it. I fixed it as above. Thanks Jonathan, again.
If you use $file then you can move the file or access it through all kinds of connections.
This solution is for scripts once the db is open.
It does not solve the problem of your users having to reset their favorites, etc.
The intermittent bug that pops up the open database dialog during an import script step has continued to be a problem. I tried your excellent suggestion to use a variable set by get (filename). I had high hopes this would squash the bug.
Unfortunately, it did not. Here are the script steps and the setup windows just to make sure I'm not missing something obvious.
We even tried deleting the contents of the user's local FileMaker Pro cache on their computer thinking some reference to the old server path name might have be in the cache. That did not help.
This bug is not with just this one script. Any script in the database that has an import script step which imports from one table to another table within the database might pop up the open dialog when the import step is reached.
The bug might not show up the first few times the script is run or it might show up the first time. It might show up four times in a row and then finally work on the fifth try.
It seems the bug has been solved. The cause was the server computer connected to both Wi-Fi and Ethernet. We noticed two ethernet addresses were displayed at the top of the Status page of the Admin Console. Wi-Fi was then turned off and the server computer restarted. In the last day and a half since then there have been no reports of the open dialog bug.
It's possible it was the restart of the computer that cleared the bug. I'm fairly certain the server computer was restarted at least once after the bug first appeared but my memory is sketchy so I don't know for sure.
Dummy Me! I said use Get(filename) rather than Get(filepath) which will work. It contains the complete filepath to the active file and should get the server path as well as a local filepath if that is the case.
Try it again...