Yuku free message boards

Oh I get it...I didn't know about the CrLf default, because the Line Delimiter box on the UI is empty.

This MIGHT work in some cases, because the first 2 file types I mapped had a character, such as * in the Nth position (the end) of each line. So, if we join all the lines in a text editor, then change the map to show the *, then all will work, right?

My concern is those files which don't, by definition, have any character defined as the last character of a record. The records are implied by their length, and the entire file is one text string, with no CrLf's.

I see two solutions:

1: Get my trading partner to alter the spec for each file, adding a known character to the end of each locical record. This may or may not be easy. We're in the early stages of designing a spec, so should be able to do this.

2: (Preferred method) Get you to add a Record Length property to the high level definition of the map. This would be used, if supplied, instead of the Line Delimiter property, to determine when each record ends. The reason this method is preferred, is because then anybody could use it for any type of file. I imagine it would override the other property entirely, and cause the translator to ignore that.

What do you think?

I'd be happy with the line width on the record level. I just assumed that all would be the same width, because in my experience they have been. It makes sense to supply it for each line, as you said. That would still override the document-level Line Terminator, right (It doesn't make sense that you'd need both...)?

Does this program REQUIRE an EDI-type file with every line containing a LineID in position x? I had a file that looked like:

 HDRDTLField 1     Field 2   etc.DTLField 1     Field 2   etc.

That works fine. I also got it to work with an asterisk line terminator after some work. I noticed that you need to not only define the line terminator in the ltm file, but unlike using the CrLf terminator, you also have to define the asterisk as a field on each line, otherwise you get errors. Now the file looks like:

 HDR*DTLField 1     Field 2   etc.*DTLField 1     Field 2   etc.*

BUT...when I try to use records without any line identifier at all, I get an error -1. The file looks either like this:

 Field 1     Field 2   etc.Field 1     Field 2   etc.

or like this:

 Field 1     Field 2   etc.*Field 1     Field 2   etc.*

I've removed the header record entirely from the ltm file for these last two examples. There's only one record type. Why do I get an error if I don't use a line identifier?

Sorry, spe (stupid programmer error) occurred. I don't have to declare the field at all. In fact, I don't even have to declare the line identifier field. What I DO have to do is have an identifier of some type on every record. So if my file looks like:

 RECMyID1  MyName1    *RECMyID2 MyName2    *etc...

I only have to define the ltm with ID at position 4 for 6, and name at position 10 for 11, then use * for line terminator, and add REC as the record identifier, and make sure it's at position 1.

I'm surprised you can't do a mapping without having a record identifier at all. This program seems tailored for EDI files, but many times we get flat data files from other systems, and it would be quite valuable to be able to translate them. I tried this several times with different test files, and it keeps generating an index out of bounds (-1) error. Please consider this as an official enhancement request (or, if this already does work, explain why I'm such a dork that I can't figure it out).

What if you just have a list of data in a text file:

 FIELD1    FIELD2    FIELD3               FIELD4FIELD1    FIELD2    FIELD3               FIELD4FIELD1    FIELD2    FIELD3               FIELD4

No line identifiers, just data. In the LTM file, you could define one record containing several fields. Logically, there is no need for a line identifier, since there is only one line type. This should work the same as a file like the following, in which you HAVE defined a line identifier (DTL):

 DTLFIELD1    FIELD2    FIELD3               FIELD4DTLFIELD1    FIELD2    FIELD3               FIELD4DTLFIELD1    FIELD2    FIELD3               FIELD4

The advantage of the latter approache is, of course, that you CAN have other line types, such as header data and detail data.

I still submit that we sometimes receive files with no line identifier, and need to parse them. Linquist should allow no line identifier, and the dll should not try to identify a line if no line identifier is in the LTM file. It should assume that all lines are of that "type". If more than one line type is defined in the LTM, then it's up to us as programmers to properly define the file to match the data.

This is all easy to say, and I'm not sure how you would accomplish this. Maybe if only one record is defined in the LTM, then Linguist doesn't complain if no line type. Maybe the dll has to count the records defined in the LTM and if only 1, and no line identifier defined, don't rely on it to identify a line. Just use the entire line, or use the line delimiter defined to logically identify records.