I have a main loop that knows that I'm inside of a particular kind of transaction/message/document, whatever you want to call it. The document consists of several segments. Within that loop, a line gets read from the file, and is immediately parsed into elements. At this point it is simply a collection of elements (like an array).

Then, based on the type of segment, I grab only the information I care about and push it into fields in tables. So my approach is similar to what Kirk said...design it for the information you are going to actually use, and only map that data, as you are reading it.

So it doesn't matter if there are 7 kinds of segments, or 50. I just add the segment type to a case statement, and grab the fields I need. And if I don't need anything out of that kind of segment, I simply ignore it.

>I think my thought was to have separate segment cursors because of the 255 field limit. There could be, in another application of this functionality, 10 or 15 segments. I would not be able to handle all of them in one cursor (MSH_Field001, MSH_Field002, EVN_Field001, etc) as I would run out of space. I thought that having the cursor in different segments with a unique key tying them together was smart. Then after talking with you, thought that having a driving cursor for the handling of the message-level stuff would allow me to keep up with what message have been processed and just use the segment cursor to process the data through my data dictionary. But, maybe I'm way off...
>