also the original field, if number type, hasn't any leading and trailing zeros.
You could format the field to show them but really they aren't there.
The solution is to use a text field with a calculation result that writes those zeros.
This begs the question why to move records from one table to another, presumably related, table.
Thanks for the quick response. I have to use this export - import method because the tables are not related (rather than using a duplicate script).
That is said, the two field, the one exporting and the ont importing the Item No field, are already in text format. For sure I could use a calculation that adds a certain amount of 0s but the issue is that it is only certain records that have them. It is part of already existing data that cannot be modified.
So the issue stands... how can I make sure that the information that is export/imported is "as is"? Would a GetasText line or something like that be helping?
You've answered why you think that import/export is needed as a method to copy the data but not why you think it is necessary to copy the data at all. Often, in relational database design, this is not needed so you may be needlessly complicating the design of your system.
"the tables are not related" raises a whole set of additional issues to be answered by "Why aren't they related?"
As Raybaudi has stated: The data in the field IS imported as is. It is the formatting of that value that may or may not be imported. Fields of type number do not store leading zeroes. IF you have fields where you have numeric digits preceded by leading zeroes, you either have data in a field of type text or a calculation field with text specified as the result type, not number an it should be imported into a corresponding field of type text.