Open the source file first. If all you do is execute the Import, FileMaker will close the file after each operation. What you're seeing is each new open event.
The user/password is requires since the database file is being newly opened for each import. If the import script step has to open a closed file, it closes it after it is done. This results in the behavior you are experiencing.
The script cannot save the user/password since that part of the user's interaction is inaccessible (by design).
Chances are that there isn't a good way out of your current situation, but you can make modifications to your new solution to facilitate uprades to it. It might be that your old solution has some of the features necessary to use one of the following methods, or you might modify your current solution to use one. These also might inspire you to create a method that works better for your situation.
You can modify the scripting of your import to first Open File and provide the user/password once.
After all of the import steps are done, you can then Close File.
This may not give you the desired results because "If the source file is open, the found set is imported; if not, all records in the source table are imported."
When using this method, you need to have some way of controlling the Found Set of the source file that is open.
The last time I used this method (FileMaker Pro 5.5), the Found Set in a table was the Found Set of the last user who closed the file leading to an unpredictable Found Set.
When I used this method, I put a script into the database "Show All Records in every table" that I could call from the updated version just prior to importing the data. This requires planning for updating. Perhaps you already have a scripted action such as a find script you can call that will have the desired effect.
Modify your new version of the database file to have the old database file as an External Data Source. This might not be possible if you have locked down the File Access priviledges in your old database. This method would require the user/password only once. Once the old database file is an External Data Source, you can add Table Occurrences, Layouts, and the appropriate scripting to copy records from one Table Occurrence to another.
Add a read-only default login account to the old solution that cannot execute scripts or do anything other than what is required to support importing from another FileMaker database. This is one that requires planning for updating, but allows you to import data into the updated solution without worry about user/pass or the need to show all records in the found set. This is an option only for those databases where you aren't trying to secure the records against copying, but merely editing.
I use method A all the time. Works a treat. Just have a folder of “Upgrade” scripts that does what you need so you can segregate it off from the rest of the scripts in the solution.
Great advice Mike and Tom! Thank you both very much. That's excellent info, and saving me a lot of headache.