It may be just a matter of preference. Some considerations:

If your backend is on a network, transfer times may be affected with the added data if you leave it on each line.
If you're going for true normalization, then you would definitely want to have the filepath and timestamp in the parent table and just an ID foreign key in the child table. Something like:

ImportT:
ImportID (Primary Key)
ImportFilePath
ImportDateTime
--- and any other fields in the main table

Then
ImportDetailT:
ImportDetailID (Primary Key)
ImportID (Foreign Key)
--- Whatever other fields to hold the imported data/text

Obviously, adjusted for your table/field names.

Would be very similar to the OrderT and OrderDetailT in Richards TechHelp Free Template.

Donald is exactly right. This is really a header/detail situation. If one imported file creates many records, then the file path and import date belong in a parent table, and the imported rows belong in a related child table. That keeps you from storing the same file information over and over again and makes the database easier to maintain later.

Nice answer, Donald.

Boy Richard, Burning the candle at both ends on opposite sides of the country. now that's dedication!

Thanks !

Dave always try to hop in the forums whenever I can, no matter where I'm at. It was awesome meeting you and your awesome shirt. :)

Picked this one for QQ87 coming out tomorrow.

Also see Normalizing Data