Allan,

It had occurred to me that you may have needed a general solution. Even that case, the fields (and conversion info) could be stored in a table, and the information could still be delimited on the fly. This information would be read in one time at the beginning of the export.

My thinking was that the more records you had to process, the less efficient your method would be. But I could be completely wrong...the performance hit could be negligible, or non-existant.

I know I would be doing it both ways, and testing the times.

I hope the project turns out well for you!

>Steve,
>
>Tks for the detailed reply.
>One of the features of this particular part of the application is that the end-use can choose which fields and in which order they will appear in the ASCII file. They can also insert literals such as 'HEADER','DETAIL', etc to identify to the records to the accounting app. Also, for non character fields, they can specify that they want the fields to be converted to a character field.
>In other words, I am trying to write a generic type of extract and one that meets the needs of this specific client.
>As a result, I build a SQL command to extract the data that is required, in the order necessary. As I am building this command, I use 'as' commands to convert numerics to characters, etc.
>At this point in the code, I can use a 'copy to delimited' and the resulting ASCII file should be formatted exactly to the accounting apps requirements.
>
>One of the other alternatives that we discussed was extracting the records and then building a string (in code) with the fields in the correct order with the required delimiter added by the program. We thought that for larger volumes the method that we chose was more efficient.
>
>