I seem to be having issues keeping my import scripts nicely lined up.  I am trying to set up a script for importing a file on a recurring basis.  There are new files put out (updated data) and I want to import those the same way each time.  So I have created a script that lines up the fields in the file.

 

First off, you have to provide it a filename (it seems) in order to even get field names with which to do alignments.  Makes some sense, as it doesn't know what fields are named in the file if it doesn't have a file.  But then if you delete that filename from the 'add file' window, those names go away.

 

So then if you take the next file you want to import doesn't appear to be working, or you open the DB on a different computer, or in a different directory, and you go open the 'Import...' script step, all the names are un-arranged.  So to proceed any further you have to rearrange everything again.

 

Is this just because the original file template-name was deleted?  What if the name was still there but the file itself wasn't?

 

In short, how do I keep this alignment consistent?

 

Thanks,

J

IBut then if you delete that filename from the 'add file' window, those names go away.

 

Try leaving the original filename and only uncheck the 'Specify data source' option.

Hmm...might be possible, except that I am using 'Specify Data Source' to also specify the file the end user is picking.  Using the container field trick to allow the user to pick a file, then the script defines a path variable for that file and it is included in the import step.

 

Although...leaving that unselected pops up a picker dialog; and you can still leave the 'no dialog' option on in order to bypass the field alignment dialog.  But then I can't use the filename in other places (e.g. saving it to a field for tracking/history).  And I don't want to show them two file pickers.  Any further thoughts?

 

Thanks,

Justin

I am unable to reproduce your issue. I suggest you print out your script to see exactly what is stored in your Import Records script step; it should look something like:

Import Records [ Source: “$path”; Target: “YourTable”; Method: Add; Character Set: “Default”; Field Mapping: 
Source field 1 import to YourTable::Somefield
Source field 2 import to YourTable::Anotherfield ] 
[ No dialog ]

I will look at printing it out; I hadn't realized it showed you that information.  Good to know.

So 'printing' out the script did help quite a bit.  Nothing was getting actually lost, as you thought.  It is just disconcerting to open that script step and see a bunch of blank source-items for the mapping.  I wish that the import interface were better.  So most of the problems were of my own doing.  I realized that I had also made a mistake when trying to export a DBF file into other formats:  when I exported it I did it in such a way that the fields had become alphabetized, instead of matching the original file's sequence.  So my secondary sample files had things in a different order.

 

One thing that I think I did find was that when using 'update matching records...' in the Import script step will cause problems when you import into an empty table.  It obviously don't have anything to match against at that point, but it thus switches to NOT importing that field at all.  It would actually, in my most recent tests, only create 1 new record when there were 300,000+ records in the file being imported.  But then everything worked fine if you run it again, because now there is one record.

 

So, I just put in an IF check on the table being imported into and made an alternate form of the import script step that just imports everything without checking.  Well, it already checked and found none, so it doesn't have to check further.  Then the IDs get correctly imported the first time and new ones added as new records after that.

 

--  J