I routinely import a csv file into a temp table. Occasionally, I need to edit the field mapping, I was under the impression scripted imports could not be edited and had to be rebuilt when changes were required.
However, today I read a comment on another forum which stated, “You can edit it directly in the script if you have the data source loaded…”
Question: Is editing a scripted import possible, and what does “have the data source loaded” mean?
If you mean that the user can't save his mapping when the script runs, as suggested by @Malcolm, then you are correct. The user will be able to map the import, however that mapping will be forgotten once the import completes.
If you mean that you can't save a mapping change by editing your script, then you are incorrect. Editing the import mapping when editing a script is saved when you re-save the script.
Agree, this is confusing. You can edit the field mapping in the script, but you can only do this if you have an actual file selected in the Specify Data Source option. But sometimes that file doesn't exist yet (perhaps it is the result of a download step, or a previous export step).
Basically, I set up 2 import files - the first one only exists on my development machine for TEST, and I can use that to set up the import mapping.
When running on another computer in PRODUCTION, the first path is not found, but the second path (set via a variable I call $path in the script) is found.
One needs to be careful with this technique, as behavior is now dependent on which machine is being used, but I find it comes in handy sometimes...
I do this too, but in reverse. The production path goes first, the development path second.
The system will probe for each file in the list until it gets a result. That takes time, and I don't want to waste time probing for test data --but most importantly-- what would happen if development path resolved correctly for a production user?