I have 50 records in File A.

Each record has a number of fields. (Call them Field X, Field Y, Field Z, etc.)

I am attempting to build File B that will contain a single field (Field XX) that will contain the information from multiple fields in File A.

However, I am trying to do this in this manner.

File B - Field XX:

1st 50 records = info from File A - Field X

2nd 50 records = info from File A - Field Y

3rd 50 records = info from File A - Field Z.

Is this possible?

Should I repost in another area?

Thank you.

Yes, it is possible. I believe it would be a single time process.

Do show all records in FileA.

You can run three imports from FileB. In the first import, import records from FileA by mapping FieldX to FieldA.

In your second import, map FieldA with FieldY

In your third report, map FieldA with FieldZ.

I was afraid of that.

80+ fields, 500+ runtime files to process.

Was hoping for a "no user intervention" as the users of our runtimes are not normally computer savvy.

Thank you for the quick response though.

You can write a script to do that. Running the script would not require any user intervention.

Tried a script.

Got the first 50 from File A - Field A into the first 50 records of File B - Field XX.

However, could not get the 50 from File A - Field B to populate the next 50 records in File B - Field XX.

I am relatively competent in scripting but cannot get this one to go.

Frankly, I'm lost. I've toosed the old scripts and am ready to start fresh.

Any ideas?

In 6, you will need to use three different scripts to retain the correct import order for each one. Before creating each script, manually perform the appropriate import for it. Then use the Import Records [Restore, No dialog] script step in the relevant script. Your main parent script in File A can show all records, then call each external import script in File B in turn.

have you tried creating a calculation field in file A - something like:

Calcfield... Field x&"¶"&Field y&"¶"&Field z

.... and then just import just that calculation field into file B

maybe that would work?

Queue -

Did as you suggested. Works great.

Added a "purge" script after the 70 import scripts to remove any unwanted blanks.

Thank you

70 import scripts? You should only need three, unless you greatly underexaggerated your setup. :wink2:

70 fields x 50 records apiece into 1 field with 3500 records.

Needed 50 records of fields A to be the 1st 50 of field XX in new file. Imported files matching Field A to Field XX > New script saving the import. That was script 1.

50 records of fields B to be the next 50 of field XX in new file. Imported files matching Field B to Field XX > New script saving the import. That was script 2.

On and on, ad nausium till script 70. Then the purge script (as not all records had data). These were combined under script "Import n Purge"

Each import was a seperate sub-script of the main "Import n Purge" script. So technically the user runs one script but I wrote 70+.

Worked. Was there a better way?

Then, yes, three was a bit of an underexaggeration for seventy. :

I must ask what purpose this piece of your solution serves. It seems like quite a workaround for something.

Our program is going the way of the Dodo.

Ours was an inspection program with extensive comments in a "library". Library had the 70 fields (one for each inspected subsystem). Program came with up to 50 canned comments for each subsystem. End users could add more.

New software replacing it has only one field for comments. My "Translator" was designed to grab the comments from the old file, funnel them into one field, purge blanks, then export to a compatible TAB file the new SW can import.

Trying to make it as simple as possible for end users. (A very point and click, don't wanna import/export crowd)

Thanks again to all who assisted.